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This publication provides customer 


engineers and other technical personnel 
with information describing the internal 


organization and operation of the FORTRAN 


IV 


grated library of IBM System/360 Operating 
System Program Logic Manuals. 


(H) compiler. It is part of an inte- 


cations required for an understanding of 
the FORTRAN IV (H) compiler are: 


IBM System/360: Principles of Opera- 
tion, Form A22-6821 


IBM System/360 Operating System: 


manuals are related to this publication and 


FORTRAN IV, Form C28-6515 


Introduction to Control Program Logic, 


Program Logic Manual, Form Y28-6605 


FORTRAN IV (H) Programmer's Guide, Form 


C28-6602 


Although not required, the following 


Should be consulted: 


IBM System/360 Operating System: 


1. 


Sequential Access Methods, Program Logic 


Manual, Form Y28-6604 


Concepts and facilities, Form C28-6535 


Supervisor and Data Management Macro 
Instructions, Form C28-6647 


Linkage Editor, Program Logic Manual, 
Form Y28-6610 


System Generation, Form C28-6554 
This manual consists of two parts: 
An Introduction, describing the FOR- 


TRAN IV (H) compiler as a whole, 
including its relationship to the 


Other publi- 


PREFACE 


operating system. The major com- 
ponents of the compiler and the rela- 
tionships among them are also 
described. 


2. A Body, containing a description of 
each component. Each component is 
discussed in terms of the functions it 
performs and the level of detail pro- 
vided is sufficient to enable the 
reader to understand the general 
operation of the component. In the 
discussion of each function of a com- 
ponent, the routines that implement 
that function are identified by name. 
The inclusion of a compound form of 
the routine names provides a frame of 
reference for the comments and coding 
supplied in the program listing. The 
program listing for each identified 
routine appears on the microfiche card 
having the second portion of the com- 
pound name of that routine in its 
heading. For example, the routine 
referred to in this manual as STALL- 
IEKGST is listed on the microfiche 
card headed IEKGST. This section also 
discusses common data, such as tables, 
blocks, and work areas, but only to 
the extent required to understand the 
logic of the components. Flowcharts 
and routine directories are included 
at the end of this section. 


Following the second part are a number 
of appendixes, which contain descriptions 
of tables used by the compiler, intermedi- 
ate text formats, a section on object-time 
library subprograms, the overlay structure 
of the compiler, and other reference 
material. 


If more detailed information is 
required, the reader should refer to the 
comments and coding in the FORTRAN IV (H) 
program listing. 
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This section contains general informa- 
tion describing the purpose of the FORTRAN 
IV (H) compiler, its relationship to the 
operating system, its input/output data 
flow, its organization, and its overlay 
structure. 


PURPOSE OF THE COMPILER 


The IBM System/360 Operating System 
FORTRAN IV (H) compiler transforms source 
modules written in the FORTRAN IV language 
into object modules that are suitable for 
input to the linkage editor for subsequent 
execution on the System/360. At the user's 
option, the compiler produces optimized 
object modules (modules that can be 
executed with improved efficiency). 


THE COMPILER AND OPERATING SYSTEM/360 


The FORTRAN IV (H) compiler is a proces- 
Sing program which communicates with the 
System/360 Operating System control program 
for input/output and other services. A 
general description of the control program 
is given in the publication IBM System/360 


Operating System: Introduction to Control 
Program Logic, Program Logic Manual. 


A compilation, or a batch of compila- 
tions, is requested using the job statement 
(JOB), the execute statement (EXEC), and 
data definition statements (DD). Cataloged 
procedures may also be used. A discussion 
of FORTRAN IV compilation and the available 
cataloged procedures is given in the publi- 


cation IBM System/360 Operating System: 
FORTRAN IV (H) Programmer's Guide. 


The compiler receives control from the 
calling program (e.g., job scheduler or 
another program that calls, links to, or 
attaches the compiler). Once the compiler 
receives control, it communicates with the 
control program through the FORTRAN system 
director, a part of the compiler that con- 
trols compiler processing. After compiler 
procesSing is completed, control is 
returned to the calling program. 





INPUT/OUTPUT DATA FLOW 


The source modules to be compiled are 
read in from the SYSIN data set. Compiler 
output is placed on the SYSLIN, SYSPRINT, 
SYSPUNCH, SYSUT1, or SYSUT2 data Set, 


SECTION 1: INTRODUCTION 


depending on the options specified by the 
FORTRAN programmer. (The SYSPRINT data set 
is always required for compilation.) 


The overall data flow and the data sets 
used for the compilation are illustrated in 
Figure 1. 


COMPILER ORGANIZATION 


The IBM System/360 Operating System 
FORTRAN IV (H) compiler consists of the 
FORTRAN system director, four logical pro- 
cesSing phases (phases 10, 15, 20, and 25), 
and an error-handling phase (phase 30). 


Control is passed among the phases of 
the compiler via the FORTRAN system direc- 
tor. After each phase has been executed, 
the FORTRAN system director determines the 
next phase to be executed, and calls that 
phase. The flow of control within the cam- 
piler is illustrated in Chart 00. (Charts 
are located at the end of Section 2.) 


The components of the compiler operating 
together produce an object module from a 
FORTRAN source module. The object module 
is acceptable as input to the linkage edi- 
tor, which prepares object modules for 
relocatable loading and execution. 


The object module consists of control 
dictionaries (external symbol dictionary 
and relocation dictionary), text (repre- 
senting the actual machine instructions and 
data), and an END statement. The external 
symbol dictionary (ESD) contains the 
external symbols that have been defined or 
referred to in the source module. The 
relocation dictionary (RLD) contains infor- 
mation about address constants in the 
object module. 


The functions of the components of the 
compiler are described in the following 
paragraphs. 


FORTRAN SYSTEM DIRECTOR 


The FORTRAN system director (FSD) con- 
trols compiler processing. It initializes 
compiler operation, calls the phases for 
execution, and distributes and keeps track 
of the main storage used during the compi- 
lation. In addition, the FSD receives the 
various input/output requests of the com- 
piler phases and submits them to the con- 
trol program. 


Section 1: Introduction 11 


SYSIN 


Source 


Module (s) 


FORTRAN TV 
(H) Compiler 











SOURCE EDIT MAP LOAD 
Option Option Option Option 
Source Intermediate Object Module 
Module Output for Storage (ESD, TXT, 
Listiag EDIT Map RLD, and END 
card images) 
SYSPRINT SYSUTI SYSPRINT SYSLIN 
Structured 
Source 
Listing 
SYSPRINT 
@e Figure 1. Input/Output Data Flow 
PHASE 10 


Phase 10 accepts as input (from the 
SYSIN data set) the individual source 
statements of the source module. If a 
source module listing is requested, the 
source statements are recorded on the SYS- 
PRINT data set. If the XREF option is 
selected, a two-part cross reference is 
recorded on the SYSPRINT data set immedi- 
ately following the source listing. If the 
EDIT option is selected, the source state- 
ments are recorded on the SYSUT1 data set, 
which phase 20 uses as input to produce a 
structured source listing. If the ID 
option is selected, calls and function 
references are asSigned an internal state- 
ment number (ISN). 


Phase 10 converts each source statement 
into a form usable as input by succeeding 
phases. This usable input consists of an 
intermediate text representation (in 
operator-operand pair format) of each 
source statement. In addition, phase 10 
makes entries in an information table for 
the variables, constants, literals, state- 
ment numbers, etc., that appear in the 
source statements. Phase 10 also places 
data in the information table about COMMON 
and EQUIVALENCE statements so that main 
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storage space can be allocated correctly in 
the object module. During this conversion 
process, phase 10 also analyzes the source 
Statements for syntactical errors. If 
errors are encountered, phase 10 passes to 
phase 30 (by making entries in an error 
table) the information needed to print the 
appropriate error messages. 


PHASE 15 


Phase 15 gathers additional information 
about the source module and modifies some 
intermediate text entries to facilitate 
optimization by phase 20 and instruction 
generation by phase 25. Phase 15 is 
divided into two segments that perform the 
following functions: 


e The first segment translates phase 10 
intermediate text entries (in operator- 
operand pair format) representing 
arithmetic operations into a four-part 
form, which is needed for optimization 
by phase 20 and instruction-generation 
by phase 25. This part of phase 15 
also gathers information about the 
source module that is needed for opti- 
mization by phase 20. 


| e The second segment of phase 15 assigns 
relative addresses, and where neces- 
Sary, address constants to the named 
variables and constants in the source 
module. This segment also converts 
phase 10 intermediate text (in 
operator-operand pair format) repre- 
senting DATA statements to a variable- 
initial value form, which makes later 
assignment of a constant value to a 
variable easier. 


Phase 15 also passes to phase 30 the 
information needed to print appropriate 
messages for any errors detected during 
phase 15 processing. (This is done by mak- 
ing entries in the error table.) 


PHASE 20 


Phase 20 processing depends on whether 
Or not optimization has been requested and, 
| if so, the optimization level desired. 


| If no optimization is specified, phase 
20 assigns registers for use during execu- 
tion of the object module. However, phase 
20 does not take full advantage of all 
registers and makes no effort to keep fre- 
quently used quantities in registers to 
eliminate the need for some machine 
instructions. 


| If the first level of optimization is 
specified, phase 20 uses all available 
registers and keeps frequently used quanti- 
ties in registers wherever possible. Phase 
20 takes other measures to reduce the size 
of the object module, and provides informa- 
tion about operands to phase 25. 


If the second level of optimization is 
specified, phase 20 uses other techniques 
to make a more efficient object module. 
The net result of these procedures is to 
eliminate unnecessary instructions and to 
eliminate needless execution of 
instructions. 


During processing, phase 20 records 
directly on the SYSPRINT data set messages 
describing any errors it detects and, if 
both the EDIT option and the second level 
of optimization are selected, produces, on 
the SYSPRINT data set, a structured source 
program listing. 


PHASE 25 


Phase 25 produces an object module from 
the combined output of the preceding phases 
of the compiler. 


The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language form. It 
May contain unresolved external symbolic 
cross references (i.e., references to sym- 
boils that do not appear in the source 
module). The external symbol dictionary 
contains the information required by the 
linkage editor to resolve external symbolic 
cross references, and the relocation dic- 
tionary contains the information needed by 
the linkage editor to relocate the absolute 
text information. 


Phase 25 places the object module 
resulting from the compilation on the SYS- 
LIN data set if the LOAD option is speci- 
fied, and on the SYSPUNCH data set if the 
DECK option is specified. Phase 25 pro- 
duces an object module listing on the SYS- 
PRINT data set if the LIST option is speci- 
fied. In addition, phase 25 produces a 
Storage map if the MAP option is specified. 
Messages for any errors detected during 
phase 25 processing are also recorded 
directly on SYSPRINT. 


PHASE 30 


Phase 30 is called after phase 15 pro- 
cesSing is completed only if errors are 
detected by phases 10 or 15. Phase 30 
records on the SYSPRINT data set messages 
describing the detected errors. Serious 
errors cause the compilation to ke deleted 
before phase 20 processing begins. 


STRUCTURE OF THE COMPILER 


The FORTRAN IV (H) compiler is struc- 
tured in a planned overlay fashion, which 
consists of 13 segments. One of these seg- 
ments constitutes the FORTRAN system direc- 
tor and is the root segment of the planned 
overlay structure. Each of the remaining 
12 segments constitutes a phase or a logic- 
al portion of a phase. A detailed discus- 
sion of the compiler's planned overlay 
structure iS given in Appendix G. 
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SECTION 2: DISCUSSION OF MAJOR COMPONENTS 


The following paragraphs and associated 
flowcharts at the end of this section 
describe the major components of the FOR- 
TRAN IV (H) compiler. Each component is 
described to the extent necessary to 
explain its function(s) and general 
operation. 


FORTRAN SYSTEM DIRECTOR 


The FORTRAN System Director (FSD) con- 
trols compiler processing; its overall 
logic is illustrated in Chart 01. The FSD 
receives control from the job scheduler if 
the compilation is defined as a job step in 
an EXEC statement. The FSD may also 
receive control from another program 
through use of one of the system macro 
instructions (CALL, LINK, or ATTACH). 


The FSD: 


Initializes the compiler. 

Loads the compiler phases. 
Distributes storage to the phases. 
Processes input/output requests. 
Generates entry code (initialization 
instructions) for main programs, sub- 
programs, and subprogram secondary 
entries. 

e Deletes compilation. 

e Terminates compilation. 


COMPILER INITIALIZATION 


The initialization of compiler proces- 
Sing by the FSD consists of two steps: 


e Parameter processing. 
e Data field initialization. 


Parameter Processing 


When the FSD is given control, the 
address of a parameter list is contained in 
a general register. If the compiler 
receives control as a result of either an 
EXEC statement in a job step or an ATTACH 
or CALL macro instruction in another pro- 
gram, the parameter list has a single 
entry, which iS a pointer to the main 
storage area containing an image of the 
options (e.g., SOURCE, MAP) specified for 
the compilation. If the compiler receives 
control as a result of a LINK macro 
instruction in another program, the parame- 
ter list may have a second entry, which is 
a pointer to the main storage area contain- 
ing substitute ddnames (i.e., ddnames that 
the user wishes to substitute for the stan- 
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COMPILER CPTIONS: 


communication table - IEKAAA 


SUBSTITUTE DDNAMES: 


dard ones of SYSIN, SYSPRINT, SYSPUNCH, 
SYSLIN, SYSUT1, and SYSUT2. 


To determine the options 
specified for the compilation and to inform 
the various compiler phases of these 
options, the FSD scans and analyzes the 
storage area containing their images and 
sets indicators to reflect the ones speci- 
fied. These indicators are placed into the 
(refer to 
Appendix A, "Communication Table") during 
data field initialization. The various 
compiler phases have access to the comrmuni- 
cation table, and, from the indicators con- 
tained in it, can determine which options 
have been selected for the compilation. 


If the user wishes to 
substitute ddnames for the standard ones, 
the FSD must establish a correspondence 
ketween the DD statements having the sub- 
stitute ddnames and the DCBS (Data Control 
Blocks) associated with the ddnames to he 
replaced. To establish this necessary 
correspondence, the FSD scans the storage 
area containing the substitute ddnames, and 
enters each such ddname into the DCBDDNM 
field of the DCB associated with the stan- 
dard ddname it is to replace. 


Data Field Initialization 


Data field initialization is concerned 
with the communication table, which is a 
central gathering area used to communicate 
information among the phases of the compil- 
er. The table contains information such 
as: | 


e User specified options. 


e Pointers indicating the next available 
locations within the various storage 
areas. 


e Pointers to the initial entries in the 
various types of chains (refer to 
Appendix A, “Information Table" and 
Appendix B, “Intermediate Text"). 


e Name of the source module being 
compiled. 


e An indication of the phase currently in 
control. 


The various fields of the communication 
table, which are filled during a compila- 
tion, must be initialized before the next 
compilation. To initialize this region, 
the FSD clears it and places the option 


indicators into the fields reserved for 
them. 


PHASE LOADING 


The FSD loads and passes control to each 
phase of the compiler by means of a stan- 
dard calling sequence. The execution of 
the call causes control to be passed to the 
overlay supervisor, which calls program 
fetch to read in the phase. Control is 
then returned to the overlay supervisor, 
which branches to the phase. The phases 
are called for execution in the following 
sequence: phase 10, phase 15, phase 20, 
and phase 25. However, if errors are 
detected by phase 10 or phase 15, phase 30 
is called after the completion of phase 15 
processing. 


STORAGE DISTRIBUTION 


Phases 10, 15, and 20 require main 
storage space in which to construct the 
information table (refer to Appendix A, 
"Information Table") and to collect inter- 
mediate text entries. These phases obtain 
this storage space by submitting requests 
to the FSD (at entry point IEKAGC), which 
allocates the required space, if available, 
and returns to the requesting phase point- 
ers to both the beginning and end of the 
allocated storage space. 


Phase 10 Storage 


Phase 10 can use all of the available 
storage space for building the information 
table and for collecting text entries. At 
each phase 10 request for main storage in 
which to collect text entries or build the 
information table, the FSD reallocates a 
portion (i.e., a Sub-block) of the storage 
for text collection, and returns to phase 
10 either via the communication table or 
the storage area P10A-IEKCAA (depending 
upon the type of text to be collected in 
the sub-block; refer to Appendix B, “Phase 
10 Intermediate Text") pointers to both the 
beginning and end of the allocated storage 
Space. If the sub-block is allocated for 
phase 10 normal text or for the information 
table, the pointers are returned in the 
communication table. If the sub-block is 
allocated for a phase 10 text type other 
than normal text, the pointers are returned 
via the storage area P10A-IEKCAA. After 
the storage has been allocated, the FSD 
adjusts the end of the information table 
downward by the size of the allocated sub- 
block. This process is repeated for each 
phase 10 request for main storage space. 


Sub-blocks to contain phase 10 text or 
dictionary entries are allocated in the 
order in which requests for main storage 
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are received. (When phase 10 completely 
fills one sub-block with text entries, it 
requests another.) <A request for a sub- 
block to contain a particular type of 
entries may immediately follow a request 
for a sub-block to contain another type of 
entries. Consequently, sub-blocks allo- 
cated to contain the same type of entries 
may be scattered throughout main storage. 
The FSD must keep track of the sub-blocks 
so that, at the completion of phase 10 pro- 
cesSing, unused or unnecessary storage may 
be allocated to phase 15. 


Phase 15 Storage 


Phase 15, in collecting the text or dic- 
tionary entries that it creates, can use 
only those portions of main storage that 
are (1) unused by phase 10, or (2) occupied 
by phase 10 normal text entries that have 
been processed by phase 15. The FSD first 
allocates all unused storage (if necessary) 
to phase 15. If this is not sufficient, 
the FSD then allocates the storage occupied 
ky phase 10 normal text entries that have 
undergone phase 15 procesSing. If either 
of these methods of storage allocation 
fails to provide enough storage for phase 
15, the compilation is terminated. 


Pointers to both the beginning and end 
of the storage are passed to phase 15 via 
the communication table. Pointers to both 
the beginning and end of the allocated sub- 
block portion are passed to phase 15 via 
the communication table. If an additional 
request iS received after the last suk- 
block portion is allocated, the FSD deter- 
mines the last phase 10 normal text entry 
that was processed by phase 15. The FSD 
then frees and allocates to phase 15 the 
portion of storage occupied by phase 10 
normal text entries Letween the first such 
text entry and the last entry processed Ly 
phase 15. 


Phase 15 Storage Inventory: After the pro- 
cesSing of PHAZ15, the first segment of 


phase 15, is completed, the FSD recovers 
the sub-ktlocks that were allocated to phase 
10 normal text. These sub-blocks are 
chained as extensions to the storage space 
available at the completion of PHAZ15 pro- 
cesSing. The chain, which begins in the 
FSD pointer table, connecting the various 
available portions of storage is scanned 
and when a zero pointer field is encoun- 
tered, a pointer to the first sub-block 
allocated to phase 10 normal text is placed 
into that field. The chain connecting the 
various sub-klocks allocated to phase 10 
normal text is then scanned and when a zero 
pointer field is encountered, a pointer to 
the first sub-block allocated to SF skele- 
ton text is placed into that field. Once 
the sub-bklocks are chained in this manner, 
they are available for allocation to CORAL, 
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| the second segment of phase 15, and to 
phase 20. 


After the processing of CORAL is com- 
pleted, the FSD likewise recovers the sub- 
blocks allocated for phase 10 special text. 
The chain connecting the various portions 
of available storage space is scanned and 
when a zero pointer field is encountered, a 
pointer to the first sub-block allocated 
for phase 10 special text is placed into 
that field. After the sub-blocks allocated 
for phase 10 special text are linked into 
the chain as described above, they, as well 
aS all other portions of storage space in 
the chain, are available for allocation to 
phase 20. 


Phase 20 Storage 


Each phase 20 request for storage space 
is satisfied with a portion of storage 
available at the completion of CORAL pro- 
cessing. The portions of storage are allo- 
cated to phase 20 in the order in which 
they are chained. Pointers to both the 
beginning and end to the storage allocated 
to phase 20 for each request are placed 
into the communication table. 


INPUT/OUTPUT REQUEST PROCESSING 


The FSD routine IEKFCOMH receives the 
input/output requests of the compiler 
phases and submits them to QSAM (Queued 
Sequential Access Method) for implementa- 


tion (refer to IBM System/360 Operating 
System: Sequential Access Methods, Program 
Logic Manual.) 


Reguest Format 


Phase requests for input/output services 
are made in the form of READ/WRITE state- 
ments requiring a FORMAT statement. The 
format codes that can appear in the FORMAT 
Statement associated with such READ/WRITE 
requests are a subset of those available in 
the FORTRAN IV language. The subset con- 
Sists of the following codes: Iw (output 
only), Tw, Aw, wX, WH, and Zw (output 
only). 


Request Processing 


To process input/output requests from 
the compiler phases, the FSD performs a 
series of operations, which are a subset of 
those carried out by the IEKFCOMH/IEKFIOCS 
combination (refer to Appendix E) to imple- 
ment sequential READ/WRITE statements 
requiring a format. 
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GENERATION OF INITIALIZATION INSTRUCTIONS 


The FSD subroutine IEKTLOCAD works with 
phase 25 to generate the machine instruc- 
tions for entry into a main program, a sub- 
program, or a subprogram secondary entry 
point. These instructions are referred to 
as initialization instructions and are 
divided into three catagories: 


e Main program entry coding. 
e Subprogram main entry coding. 
e Subprogram secondary entry coding. 


Once generated, these instructions are 
entered into TXT records. See “Phase 25, 
Text Information™ for a discussion of TXT 
records. 


Main Program Entry Coding: The initializa- 
tion instructions generated by subroutine 


IEKTLOAD for a main program perform the 
following functions: 


e Save the contents of general registers 
14 through 12. 


e Load the reserved registers with their 
associated addresses. (The address 
loaded into register 13 is that of the 
Save area. The address loaded into 
register 11, if reserved, is that of 
the save area plus 4096 bytes. The 
address loaded into register 10, if 
reserved, is that of the save area plus 
8192 bytes. The address loaded into 
register 9, if reserved, is that of the 
Save area plus 12,288 bytes.) 


e Load the address of the main program 
Save area into register 4, and store 
register 4 into the save area of the 
calling program. 


e Save register 13 in the new Save area. 


Subprogram Main Entry Coding: The initial- 
ization instructions generated by subrou- 


tine IEKTLOAD for the main entry point into 
a Subprogram perform the following 
functions: 


e Save the contents of general registers 
14 through 12. 


e Load the addresses of the prologue and 
epilogue of the subprogram into regis- 
ters. (For an explanation of prologue 
and epilogue, refer to “Phase 25, Pro- 
logue and Epilogue Generation.") 


e Load the reserved registers with their 
associated addresses. 


e Load the address of the save area of 
the subprogram into register 13. 


ae 


e Save the address of the Save area of 
the calling routine and the address of 
the epilogue of the subprogram in the 
Save area of the subprogram. 


e Branch to the prologue. 


e Set up a save area in which the con- 
tents of the registers used by the sub- 
program are saved, should that subpro- 
gram, in turn, call another subprogram. 


e Set up address constants in which the 
addresses of the prologue and epilogue 
of the subprogram and the addresses to 
be placed into the reserved registers 
are inserted. 


Subprogram Secondary Entry Coding: The 
initialization instructions for a subpro- 


gram secondary entry point are essentially 
the same as those required for the main 
entry point. For this reason, IEKTLOAD 
makes use of a number of the initialization 
instructions for the main entry point in 
procesSing secondary entry points. 


Main entry point initialization instruc- 
tions that precede and include the instruc- 
tion that loads the prologue and epilogue 
addresses cannot be used, because each 
secondary entry point has its own asso- 
ciated prologue and epilogue. Therefore, 
for secondary entry points, subroutine IEK- 
TLOAD generates initialization instructions 
that perform the following functions: 


e Save the contents of general registers 
14 through 12. 


e Load the addresses of the prologue and 
epilogue of the secondary entry point 
into registers. 


e Branch to the subprogram main entry 
point initialization instruction that 
loads the reserved registers with their 
associated addresses. 


e Set up address constants in which the 
addresses of the prologue and epilogue 
of the secondary entry point are 
placed. 


Subprogram secondary entry coding does 
not occupy storage within the "Initializa- 
tion Instructions" section of text informa- 
tion. That section is reserved for: 


e Main program entry coding, if the 
source module being compiled is a main 
program. 


e Subprogram main entry coding, if a sub- 
program is being compiled. 


The initialization instructions for 
secondary entry points are generated when 
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the text representation of an ENTRY state- 
ment is encountered during the last scan of 
intermediate text. These instructions 
reside in the "Instructions" section of 
text information. 


DELETION OF A COMPILATION 


The FSD deletes a compilation if either 
of the following occurs: 


e An error of error level code 16 (refer 
to the publication IBM System/360 
Operating System: FORTRAN IV_ (H) Pro- 
grammer's Guide) is detected during the 
execution of a procesSing phase. 


e The value of the error level code 
returned from phase 30 is 8 and the 
LOAD option has not been specified. 


In the former case, the phase detecting 
the error passes control to the FSD at 
entry point SYSDIR-IEKAA9. If the error 
was detected by phase 10, the FSD deletes 
the compilation by having phase 10 read 
records (without processing them) until the 
END statement is encountered. If the error 
was encountered in a phase other than phase 
10, the FSD simply deletes the compilation. 


In the latter case, phase 30 returns 
control to the FSD at the next sequential 
instruction. If the error level code 
passed to the FSD is 8 and the LOAD option 
has not been specified, the FSD continues 
processing. 


Note: Phase 25 returns an error level code 
of 8 to the FSD if errors are detected dur- 
ing the translation of FORMAT statements. 
However, in this case, the FSD does not 
delete the compilation if the LOAD option 
has not been specified. 





COMPILER TERMINATION 


The FSD terminates compiler processing 
when an end-of-file is encountered in the 
input data stream or when a permanent 
input/output error is encountered. If, 
after the deletion of a compilation or 
after a source module has been completely 
compiled, the first record read by the FSD 
from the SYSIN data set contains an end-of- 
file indicator, control is passed to the 
FSD (at the entry point ENDFILE), which 
terminates compiler processing by returning 
control to the operating system. If a per- 
Manent error is encountered during the 
servicing of an input/output request of a 
phase, control is passed to the FSD (at 
entry point IBCOMRTN), which writes a mes- 
sage stating that both the compilation and 
job step are deleted. The FSD then returns 
control to the operating system. In either 
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of the above cases, the FSD passes to the 
operating system as a condition code the 
value of the highest error level code 
encountered during compiler processing. 
The value of the code is used to determine 
whether or not the next job step is to be 
performed. 


PHASE 10 

The FSD reads the first record of the 
source module and passes its address to 
phase 10 via the communication table. 
Phase 10 converts each FORTRAN source 
statement into usable input to subsequent 
phases of the compiler; its overall logic 
is illustrated in Chart 03. Phase 10 
conversion produces an intermediate text 
representation of the source statement and/ 
or detailed information describing the 
variables, constants, literals, statement 
numbers, data set reference numbers, etc., 
appearing in the source statement. During 
conversion, the source statement is ana- 
lyzed for syntactical errors. 


The intermediate text is a strictly 
defined internal representation (1.e., 
internal to the compiler) of a source 
statement. It is developed by scanning the 
source statement from left to right and by 
constructing operator-operand pairs. In 
this context, operator refers to such ele- 
ments aS commas, parentheses, and Slashes, 
as well as to arithmetic, relational, and 
logical operators. Operand refers to such 
elements as variables, constants, literals, 
statement numbers, and data set reference 
numbers. An operator-operand pair iS a 
text entry, and all text entries for the 
operator-operand pairs of a source state- 
ment are the intermediate text representa- 
tion of that statement. 


The following six types of intermediate 
text are developed by phase 10: 


e Normal text is the intermediate text 
representation of source statements 
other than DATA, NAMELIST, DEFINE FILE 
FORMAT, and statement functions. 


e Data text is the intermediate text 
representation of DATA statements and 
initialization values in type 
statements. 


e Namelist text is the intermediate text 
representation of NAMELIST statements. 


e Define file text is the intermediate 
text representation of DEFINE FILE 
Statements. 

e Format text is the intermediate text 
representation of FORMAT statements. 
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e SF skeleton text is the intermediate 
text representation of statement func- 
tions using sequence numbers as 
operands of the intermediate text 
entries. The sequence numbers replace 
the dummy arguments of the statement 
functions. This type of text is, in 
effect, a “skeleton” macro. 


The various text types are discussed in 
detail in Appendix B, “Intermediate Text." 


The detailed information describing 
operands includes such facts as whether a 
variable is dimensioned (i.e€., an array) 
and whether the elements of an array are 
real, integer, etc. Such information is 
entered into the information takle. 


The information table consists of five 
components: 


e The dictionary contains information 
describing the constants and variables 
of the source module. 


e The statement number/array table con- 
tains information describing the state- 


ment numbers and arrays of the source 
module. 





e The common table contains information 
describing COMMON and EQUIVALENCE 
declarations. 


e The literal table contains information 
describing the literals of the source 
module. 


e The branch table contains information 
describing statement numbers appearing 
in computed GO TO statements. 


A detailed discussion of the information 
takle is given in Appendix A, “Information 
Table." 


The intermediate text and the informa- 
tion table complement each other in the 
actual code generation by the subsequent 
phases. The intermediate text indicates 
what operations are to be carried out on 
what operands; the information table pro- 
vides the detailed information describing 
the operands that are to be processed. 


SCURCE STATEMENT PROCESSING 


To process source statements, each rec- 
ord (one card image) of the source module 
is first read into an input buffer by a 
preparatory subroutine (GETCD-IEKCGC). If 
a source module listing is requested, the 
record is recorded on an output data set 
(SYSPRINT). If both the EDIT option and 
the second level of optimization (OPT=2) 
are selected, the record and some control 


information used by phase 20 to produce a 
structured ‘source listing are recorded on 
the SYSUT1 data set. Records are moved to 
an intermediate buffer until a complete 
source statement resides in that buffer. 
Unnecessary blanks are eliminated from the 
source statement, and the statement is 
assigned a classification code. A dis- 
patcher subroutine (DSPTCH-IEKCDP) deter- 
mines from the code which subroutine is to 
continue processing the source statement. 
Control is then passed to that subroutine, 
which converts the source statement to its 
intermediate text representation and/or 
constructs information table entries 
describing its operands. After the entire 
source statement has been processed, the 
next is read and processed as described 
above. The recognition of the END state- 
ment causes phase 10 to complete its pro- 
cessing and return control to the FSD, 
which calls phase 15 for execution. 


The functions of phase 10 are performed 
by six groups of subroutines: 


e Dispatcher subroutine 
e Preparatory subroutine 
e Keyword subroutines 

e Arithmetic subroutines 
e Utility subroutines 


e STALL-IEKGST subroutine 


Dispatcher Subroutine 


The dispatcher subroutine (DSPTCH- 
IEKCDP) controls phase 10 processing. 
receiving control from the FSD, DSPTCH- 
IEKCDP subroutine initializes phase 10 pro- 
cessing and then calls the preparatory sub- 
routine (GETCD-IEKCGC) to read and prepare 
the first source statement. After the 
statement iS prepared, control is returned 
to DSPTCH-IEKCDP, which determines if a 
statement number is associated with the 
source statement being processed. If there 
is a statement number, the DSPTCH-IEKCDP 
subroutine constructs a statement number 
entry (refer to Appendix A, “Information 
Table") for the statement number. A text 
entry for the statement number is also 
- created. The DSPTCH-IEKCDP subroutine then 
determines, from the classification code 
assigned to the source statement (refer to 
“Preparatory Subroutine"), which subroutine 
(either keyword or arithmetic) is to con- 
tinue the processing of the statement, and 
passes control to that subroutine. When 
the source statement is completely pro- 
cessed, control is returned to the DSPTCH- 


Upon 


IEKCDP subroutine, which calls the prepara- . 


tory subroutine to read and a aba the 
next source Statement. 
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Preparatory Subroutine 


The preparatory subroutine (GETCD- 
IEKCGC) reads each source statement, 
records it on the SYSPRINT data set if the 
SCURCE option is selected, and on the 
SYSUT1 data set if the EDIT option and the 
second level of optimization are selected, 
packs and classifies it, and assigns it an 
internal statement number (ISN)1. Packing 
eliminates unnecessary blanks, which may 
precede the first character, follow the 
last character, or be imbedded within the 
source statement. Classifying assigns a 
code to each type of source statement. The 
code indicates to the DSPTCH-IEKCDP subrou- 
tine which subroutine is to continue pro- 
cessing the source statement. A descrip- 
tion of the classifying process, along with 
figures illustrating the two tables (the 
keyword pointer table and the keyword 
table) used in this process, is given in 
Appendix A, “Classification Tables.“ The 
ISN assigned to the source statement is an 
internal Sequence number used to identify 
the source statement. The source sState- 
ment, after being prepared, resides in the 
storage area NCARD/NCDIN in the format 
illustrated in Figure 2. 


| |NCARD | 
| | 
— | | 
|Pointer to first character of (1 word) | 
|packed source statement beyond | 
| keyword’ | 
po aS a ee al Me ee | 
JInternal statement number (1 word) | 
a aa as i ee ee | 
|Statement number indicator (#0 (1 word) | 
Jif present; 0 if not present) | 
Nh Ne ee ee atk ey A EF eh ie ee | 
|Classification code (1 word) | 
ene i eee RE ter Se Pe CRE es ee nee See aN tr tie RTE ROTO oe ee j 
ee ee a ee ee eee 1 
| NCDIN | 
| | 
| | 
|Statement number (5 bytes) | 
bes ee ee eee 
| Packed source statement (n bytes) | 
bee ee ae ee eee ee eee 
{Group mark? (1 byte) | 


{*For arithmetic statements and statement | 
|functions, this field points to the first| 
|character of the packed statement. | 
|2End of statement marker. | 


Format of Prepared Source 
Statement 


ee cee ce ew ee ce se ee ee ce ee ce ee we ee 


TLogical IF statements are assigned two 
internal statement numbers. The IF part is 
given the first number and the “trailing 
Statement iS given the next. 
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Keyword Subroutines 


A keyword subroutine exists for each 
keyword source statement. A keyword source 
statement is any permissible FORTRAN source 
statement other than an arithmetic state- 
ment or a statement function. 
of each keyword subroutine is to convert 
its associated keyword source statement (in 
NCDIN) into input usable by subsequent 
phases of the compiler. These subroutines 
make use of the utility subroutines and, at 
times, the arithmetic subroutines in per- 
forming their functions. To simplify the 
discussion of these subroutines, they are 
divided into two groups: 

1. Those that construct only information 
table entries. 
2. Those that construct information table 
entries and develop intermediate text 
representations. 


Table Entry Subroutines: Only one keyword 
subroutine belongs to this group (refer to 


Table 8). It is associated with a COMMON, 
DIMENSION, EQUIVALENCE, or EXTERNAL keyword 
statement. 


This subroutine scans its associated 
Statement (in NCDIN) in a left-to-right 
fashion and constructs appropriate informa- 
tion table entries for each of the operands 
of the statement. The types of information 
table entries that can be constructed by 
this subroutine are: 

e Dictionary entries for variables and 
external names. 


e Common block name entries for common 
block names. 


e Equivalence group entries for equiva- 
lence groups. 


e Equivalence variable entries for the 
variables in an equivalence group. 


e Dimension entries for arrays. 


The formats of these entries are given 
in Appendix A, “Information Table." 


Table Entry and Text Subroutines: The key- 
word subroutines, other than the table 


entry subroutine, belong to this group 
(refer to Table 8). Each of these subrou- 
tines converts its associated statement by 
developing an intermediate text representa- 
tion of the statement, which consists of 
text entries in operator-operand pair for- 
mat, and constructing information table 
entries for the operands of the statement. 
The processing performed by these subrou- 
tines is similar and is described in the 
following paragraphs. 
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The function 


Upon receiving control from the DSPTCH- 
IEKCDP subroutine, the keyword subroutine 
associated with the keyword statement being 
processed places a special operator into 
the text area. This operator is referred 
to aS a primary adjective code and defines 
the type (e.g., DO, ASSIGN) of the state- 
ment. A left-to-right scan of the source 
statement is then initiated. The first 
operand is obtained, an information table 
entry is constructed for the operand and 
entered into the information table (only if 
that operand was not previously entered) , 
and a pointer to the entry's location in 
that table is placed into the text area. 
The mode (e€.g-, integer, real) and type 
(e.g.-, negative constant, array) of the 
operand are then placed into text. 


Scanning is resumed and the next opera- 
tor is obtained and placed into the text 
area. The next operand is then obtained, 
an information table entry is constructed 
for the operand and entered into the infor- 
mation table (again, only if that operand 
was not previously entered), and a pointer 
to the entry's location is placed into the 
text entry work area. The mode and tyre of 
the operand are placed into the work area. 
The text entry is then placed into the next 
available location in the sub-block allo- 
cated for text entries of the type being 
created. 


This process is terminated upon recogni- 
tion of the end of the statement, which is 
marked by a special text entry. The spe- 
cial text entry contains an end mark opera- 
tor and the ISN of the source statement as 
an operand. 


Note: Certain keyword subroutines in this 
group, namely those that process statements 
that can contain an arithmetic expression 
(e.g., IF and CALL statements) and those 
that process statements that contain I/O 
list items (e.g., READ/WRITE statements), 
pass control to the arithmetic subroutines 
to complete the processing of their asso- 
ciated keyword statements. 


Arithmetic Subroutines 


The arithmetic subroutines (refer to 
Table 8) receive control from the DSPTCH- 
IEKCDP subroutine, or from various keyword 
subroutines, and make use of the utility 
subroutines in performing their functions, 
which are to: 


e Process arithmetic statements. 
e Process statement functions. 
e Complete the processing of certain key- 


word statements (READ, WRITE, CALL, and 
IF.) 


The following paragraphs describe the 
processing of the arithmetic subroutines 
according to their functions. 


Arithmetic Statement Processing: In pro- 
cesSing an arithmetic statement, the arith- 


metic subroutines develop an intermediate 
text representation of the statement, and 
construct information table entries for its 
operands. These subroutines accomplish 
this by following a procedure similar to 
that described for keyword (table entry and 
text) Subroutines. 


If one operator is adjacent to another, 
the first operator does not have an asso- 
ciated operand. In the example A=B(I)+C, 
the operator + has variable C as its asso- 
ciated operand, whereas the operator ) has 
no associated operand. If an operator has 
no associated operand, a zero (null) 
operand is assumed. 


Statement Function Processing: In convert- 
ing a statement function to usable input to 


subsequent phases of the compiler, the ari- 
thmetic subroutines develop an intermediate 
text representation of the statement func- 
tion using sequence numbers as replacements 
for dummy arguments. These subroutines 
also construct information table entries 
for those operands that appear to the right 
of the equal sign and that do not corres- 
pond to dummy arguments. The following 
paragraphs describe the processing of a 
statement function by the arithmetic 
subroutines. 


When processing a Statement function, 
the arithmetic subroutines: 


e Scan the portion of the statement func- 
tion to the left of the equal Sign, 
obtain each dummy argument, assign each 
dummy argument a sequence number (in 
ascending order), and save the dummy 
arguments and their associated sequence 
numbers for subsequent uSe. 


e Scan the portion of the statement func- 
tion to the right of the equal sign and 
obtain the first (or next) operand. 


e Determine if the operand corresponds to 
a dummy argument. If it does corre- 
spond, its associated sequence number 
is placed into the text area. If it 
does not correspond, a dictionary entry 
for the operand is constructed and 
entered into the information table, and 
a pointer to the entry's location is 
placed into the text area. (An opening 
parenthesis is used as the operator of 
the first text entry developed for each 
statement function and a closing paren- 
thesis is used as the operator of the 
jast text entry developed for each 
statement function.) 
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e Resume scanning, obtain the next opera- 
tor, and place it into the text area. 


e Obtain the operand to the right of this 
Operator and process it as described 
above. 


Keyword Statement Completion: In addition 
to processing arithmetic statements and 


Statement functions, the arithmetic subrou- 
tines also complete the processing of key- 
word statements that may contain arithmetic 
expressions or that contain I/O list items. 
The keyword subroutine associated with each 
such keyword statement performs the initial 
processing of the statement, but passes 
control to the arithmetic subroutines at 
the first possible occurrence of an arith- 
metic expression or an I/O list item. (For 
example, the keyword subroutine that pro- 
cesses CALL statements passes control to 
the arithmetic subroutines after it has 
processed the first opening parenthesis of 
the CALL, because the argument that follows 
this parenthesis may be in the form of an 
arithmetic expression.) The arithmetic 
subroutines complete the processing of 
these keyword statements in the normal 
manner. That is, they develop text entries 
for the remaining operator-operand pairs 
and construct information table entries for 
the remaining operands. 


Utility Subroutines 


The utility subroutines (refer to Takle 
8) aid the keyword, arithmetic, and DSPTCH- 
IEKCDP subroutines in performing their 
functions. The utility subroutines are 
divided into the following groups: 


Entry placement subroutines. 
Text generation Subroutines. 
Collection subroutines. 
Conversion subroutines. 


Entry Placement Subroutines: The utility 
subroutines in this group place the various 


types of entries constructed by the key- 
word, arithmetic, and DSPTCH-IEKCDP subrou- 
tines into the tables or text areas (i.e., 
sub-blocks) reserved for them. 


Text Generation Subroutines: The utility 
subroutines in this group generate text 
entries (supplementary to those developed 
by the keyword and arithmetic subroutines) 
that: 


e Control the execution of implied DO's 
appearing in I/O statements. 


e Increment DO indexes and test them 
against their maximum values. 


e Signify the end of a source statement. 
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Collection Subroutines: These utility sub- 
routines perform such functions as gather- 
ing the next group of characters (i.e., a 
string of characters bounded by delimiters) 
in the source statement being processed, 
and aligning variable names on a word boun- 
dary for comparison to other variable 
names. 


Conversion Subroutines: These utility sub- 
routines convert integer, real, and complex 
constants to their binary equivalents. 


Subroutine STALL-IEKGST 


STALL-IEKGST completes phase 10 proces- 
Sing by: 


e Generating entry code for the object 
module. 


e Translating phase 10 format text into 
object code for the object module and 
freeing space formerly occupied Ly the 
format text. 


e Checking to see if any literal data 
text exists and if it does, generating 
object code for the literal data text. 


e Processing any equivalence entries that 
were equivalenced before being 
dimensioned. 


e Setting aside space in the object 
module for the problem program save 
area and for computed GO TO statement 
branch tables created by phase 10. 


e Checking the statement number section 
of the information table for undefined 
statement numbers. 


e Rechaining variables in the dictionary 
by sorting alphabetically the entries 
in each chain. | 


e AsSigning coordinates based on the 
usage count set by phase 10 when the 
OPT option iS greater than zero. 


e Processing common entries in the infor- 
mation table by computing the offset 
(displacement) of each variable in the 
common block from the start of the com- 
mon block. 


e ProcesSSing equivalence entries in the 
information table. 


Generating FORMAT Code: If the source 
module contains READ/WRITE statements 


requiring FORMAT statements, the associated 
phase 10 format text must be put into a 
form recognizable by IHCFCOMH. STALL- 
IEKGST calls subroutine FORMAT-IEKTFM which 
develops the necessary form by obtaining 
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the phase 10 intermediate text representa- 
tion of each FORMAT statement, and trans- 
lating each element (e.g., H format code 
and field count) of the statement according 
to Table 1. FORMAT-IEKTFM enters the 
translated statement along with its rela- 
tive address into TXT records. It also 
inserts the relative address of the trans- 
lated statement into the address constant 
for the statement number associated with 
the FORMAT statement. 


STALL-IEKGST reserves storage within 
text information for the variables and 
arrays of the module between the last con- 
stant and the first translated FORMAT 
statement, or the first object-time name- 
list dictionary, if FORMAT statements do 
not exist in the module. To accomplish 
this, STALL-IEKGST assigns to the first 
translated FORMAT statement (or object-time 
namelist dictionary) a relative address 
equal to the number of bytes occupied by 
the constants, variables, and arrays of the 
module. 


Processing Equivalence Entries: STALL- 
IEKGST completes the processing of any 


equivalence entries in the information 
table which were not completed by prior 
routines in phase 10. These equivalence 
entries are the ones that were equivalenced 
before being dimensioned. STALL-IEKGST 
computes offsets for each variakle in the 
equivalence group. 


Processing Literal Data Text: STALL-IEKGST 
checks a pointer in the communication table 


(NPTR (1,27)) to see if there are literal 
constants to process. If there are, STALL- 
IEKGST calls IEKTLOAD and passes it the 
location and length of the literal string 
which IEKTLOAD uses to generate literal 
data text in the object module. 


STALL-IEKGST follows the chain in the 
literal constant dictionary entry and con- 
tinues to call IEKTLOAD to process this 
text. After all the literal data text has 
been generated, STALL-IEKGST adjusts the 
relative object location counter by the 
amount of text generated. 


Reserving Space for the Save Area: STALL- 
IEKGST sets aside space for the Save area 


of the program keing compiled. The amount 
of space reserved depends on the type of 
program being processed. For a program 
with no external CALLS, 16 bytes are 
required for the save area. A program with 
external CALLS needs a Save area 76 Lytes 
long. 


Space in the object module for branch 
tables created by phase 10 for computed GO 
TO statements is also reserved Ly 
STALL-IEKGST. 


eTable 1. FORMAT Statement Translation 


aa aa a ica a ge ed 1 aa aA a a ac ea 1 
| Translated Form (in hexadecimal) | 


| | 
| FORMAT Po pe ne en en gp a ee 4 
| Specification | Description | ist byte | 2nd byte | 3rd byte | 
|-~-----~-~--------- {---------------------------- {------------ +--------~---}------------ { 
| | beginning of statement | 02 | | | 
| n ( | group count | O04 | n | | 
| n | field count | 06 | n | | 
| nP | scaling factor | 08 | n* | | 
| Fw.d | F-conversion | OA | W | d | 
| Ew.d | E-conversion | OC | W [ d | 
| Dw.d | D-conversion | OE | W { dq | 
| Iw I-conversion | 10 | W | | 
| Tn | column set | 12 | n | | 
| Aw | A-conversion | 14 | Ww | | 
| Lw | L-conversion | 16 | Ww { | 
| nX | skip or blank | 18 | n | | 
| nitext | | | | | 
| or | literal data | 1A | n | text | 
| "text! | | | | | 
| ) | group end | ve | | | 
| / | record end | 1E | | [ 
| Gw.d | G-conversion | 20 | W | d | 
| | end of statement | 22 { | | 
| ZW | Hexadecimal conversion | 24 | w | | 
fae ee Ease ant eas en er cee eer ee stey eee eee gaye eer ee BO Bo pea earn eee eelp ane 4 
|*The first hexadecimal bit of the byte indicates the scale factor sign (0 if positive, | 
{1 if negative). The next seven bits contain the scale factor magnitude. | 
BIN Nhe te Acca Sem Fe ee oN ene ge a ee a i es es Se J 
Checking for Undefined Statement Numbers: to variakles and constants in the following 
STALL-IEKGST performs a dictionary scan for Manner: 
undefined statement numbers. This action 
is taken to ensure that every statement e The first 59 unique variables and/or 
number that is referred to is also defined. constants appearing in the text created 
STALL-IEKGST scans the chain of statement by phase 10 are assigned coordinates 2 
number entries in the information table through 60, respectively.! The coor- 
(refer to Appendix A: "Statement Number/ dinates are asSigned in order of 
Array Table") and examines a bit in the increasing coordinate number. (A coor- 
byte A usage field of each such entry. dinate ketween 2 and 60 may Le assigned 
This bit is set by phase 10 to indicate to a base variable if fewer than 59 
whether or not it encountered a definition unique variables and constants appear 
of that statement number. If the bit indi- in the text.) 
cates that the statement number is not 
defined, STALL-IEKGST places an entry in e The next 20 unique variables are 
the error table for later processing by assigned coordinates 61 through 80, 
phase 30. respectively. The coordinates are 
asSigned in order of increasing coor- 
Rechaining Entries for Variables: STALL- dinate number. (If constants are 
IEKGST scans dictionary entries for encountered after coordinate 60 has 
variables. Previously executed routines in been assigned, they are not assigned 
phase 10 sorted each variable chain alpha- coordinates.) 
betically and left the pointer at the mid- 
item of the chain (for dictionary search e The coordinates 81 through 128 are 
Speed). STALL-IEKGST resets the pointer to reserved for assignment to base 
the first (alphabetically lowest) item in variakles (refer to CORAL ProcesSing, 
the chain. The rechaining frees storage in "“Adcon and Base Variable Assignment") . 
each entry for later use by CORAL in phase 
15. It then sets the adcon field of each Sa = SSeS SS 
dictionary entry for a variable to zero. 1The coordinate 1 iS assigned to items such 
STALL-IEKGST also constructs dictionary aS unit numbers (i.e., data set reference 
entries for the imaginary parts of complex numbers) , complex variables in common, 
variables and constants. arrays that are equivalenced, variables 
that are equivalenced to arrays, and 
Assigning Coordinates: STALL-IEKGST calls variables that are equivalenced to 


subroutine IEKKOS which assigns coordinates variables of different modes. 
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Subroutine IEKKOS assigns the first 
variable or constant in phase 10 text a 
coordinate number of 2, which indicates 
that the usage information for that vari- 
able or constant, regardless of the block 
in which it appears, is to be recorded in 
bit position 2 of the MVS, MVF, and MVX 
fields. IEKKOS assigns the second variable 
or constant a coordinate number of 3 and 
records its usage information in bit posi- 
tion 3 of the three fields. IEKKOS con- 
tinues this process until coordinate 60 has 
been assigned to a variable or constant. 
After coordinate number 60 has been 
assigned, IEKKOS only assigns coordinates 
to the next 20 unique variables. IEKKOS 
does not assign coordinates to or gather 
usage information for unique constants 
encountered after coordinate number 60 has 
been assigned. It assigns these variables 
coordinates 61 through 80, respectively. 
It records the usage information for each 
variable at the assigned bit location in 
the three fields. IEKKOS does not assign 
coordinates to or gather usage information 
for unique variables encountered after 
coordinate number 80 has been assigned. 


Subroutine IEKKOS uses a combination of 
the MCOORD vector, the MVD table, and the 
byte-C usage fields of the dictionary 
entries (refer to Appendix A, “Dictionary") 
to assign, keep track of, and record coor- 
dinate numbers. MCOORD contains the number 
of the last coordinate assigned. The MVD 
table is composed of 128 entries, with each 
entry containing a pointer to the dic- 
tionary entry for the variable or constant 
to which the corresponding coordinate num- 
ber is assigned or to the information table 
entry for the base variable to which the 
corresponding coordinate is assigned. The 
coordinate number assigned to a variable or 
constant is recorded in the byte-C usage 
field of the dictionary entry for that 
variable or constant. 


Subroutine IEKKOS does not assign coor- 
dinates to or record usage information for 
unique constants encountered in text after 
coordinate number 60 has been assigned and 
unique variables encountered in text after 
coordinate number 80 has been assigned. If 
IEKKOS encounters a new constant after 
coordinate 60 has been assigned or a new 
variable after coordinate 80 has been 
assigned, it records a zero in the byte-C 
usage field of its associated dictionary 
entry. Phase 20 optimization deals only 
with those constants and variables that 
have been asSigned coordinate numbers 
greater than or equal to 2 and less than or 
equal to 80. 


Processing Common Entries in the Informa- 
tion Table: STALL-IEKGST processes common 


entries in the information table. It com- 
putes the offsets (displacements) of 
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variables and arrays from the start of the 
common block containing them and calculates 
the total size in bytes of each common 
block. STALL-IEKGST records the offsets in 
the dictionary entries for the variables 
and the block size in the common table 
entry for the name of the common block. 

The offsets are used later to assign rela- 
tive addresses to common variables. The 
block size is used by phase 25 to generate 
a control section for the common block. 
(Refer to Appendix A: “Common Table.") 
STALL-IEKGST also places a pointer to the 
common table entry for the block name in 
the dictionary entry for each variable or 
array in that common block. 


Processing Equivalence Entries in the 
Information Table: STALL-IEKGST gathers 


additional information about equivalence 
groups and the variakles in them. It com- 
putes a group head’? and the offset (dis- 
placement) of each variable in the group 
from this head. It records this informa- 
tion in the common table entries for the 
group and for the variables, respectively. 
(Refer to Appendix A: “Common Table".) 
STALL-IEKGST identifies and flags in their 
dictionary entries variables and arrays put 
into common via the EQUIVALENCE statement. 
It also checks the variables and arrays for 
errors to verify that the associated common 
block has not been improperly extended 
because of the EQUIVALENCE declaration. If 
a common Llock is legitimately enlarged by 
an equivalence operation, STALL-IEKGST 
recomputes the size of the common block and 
enters the size into the common table entry 
for the name of the common block. 


If the name of a variable or array 
appears in more than one equivalence group, 
STALL-IEKGST recognizes the combination of 
groups and modifies the dictionary entries 
for the variables to indicate the equiva- 
lence operations. STALL-IEKGST checks 
arrayS appearing in more than one equiva- 
lence group to verify that conflicting 
relationships have not been estaklished for 
the array elements. 


During the processing of both common and 
equivalence information, a check is made to 
ensure that variables and arrays fall on 
boundaries appropriate to their defined 
types. If a variable or array is improper- 
ly aligned, STALL-IEKGST places an entry in 
the error table for processing by phase 30. 


1The head of an equivalence group is that 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 


CONSTRUCTING A CROSS REFERENCE 


If the XREF option is selected, a two 
part cross reference is constructed and 
written on the SYSPRINT data set immediate- 
ly following the source listing. The first 
part of the cross reference is a list of 
all symbols used by the program and the 
ISNs of the statements in which each symbol 
appears. The symbols are written in alpha- 
betic order and grouped by character 
length, first one-character symbols in 
alphabetic order, then two-character sym- 
bols in alphabetic order, etc. The second 
part of the cross reference is a sequential 
list of the statement numbers used on the 
program each followed by the ISN of the 
Statement in which the statement number is 
defined and also by a list of the ISNs of 
Statements that refer to the statement 
number. 


XREF procesSing occurs during phase 10 
and in a small separate overlay segment 
between phases 10 and 15. This segment, 
XREF-IEKXRF, is called only if the XREF 
Option is selected. 


Phase 10 Preparation for XREF Processing 


If the XREF option is chosen phase 10 
Subroutines LABTLU-IEKCLT and CSORN-IEKCCR 
perform additional processing for statement 
numbers and symbols. Also, phase 10 sub- 
routine IEKXRS, which is not used unless 
the XREF option is chosen, is called. 


LABTLU-IEKCLT fills the adcon table, 
which is used as an XREF buffer, with XREF 
entries for statement number definitions 
and statement number references. The for- 
mat of an XREF entry for statement numbers 
and symbols is: 


|Pointer to next 
|XREF entry* 


* Relative to the beginning of the buffer. 


Each time the buffer is full, LABTLU- 
IEKCLT calls IEKXRS to write the buffer on 
SYSUT2. (The contents of SYSUT2 is later 
read in by XREF-IEKXRF and processed to 
produce a cross reference.) A count of the 
number of times the buffer is written out 
is kept in the communication table NPTR 
(2,20). Each time it finishes writing the 
buffer on SYSUT2, IEKXRS returns control to 
LABTLU-IEKCLT. 


LABTLU-IEKCLT uses parts of the dic- 
tionary entries for statement numbers as 
pointers to keep track of its processing. 
It also adds a word (word 9) to each state- 
ment number dictionary entry to be used as 
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a sequence chain field so that XREF-IEKXRF 
can create a sequential list of statement 
numbers used in the program. 


The words used by LABTLU-IEKCLT in dic- 
tionary entries for statement numbers are: 


Word 5 - A pointer to the most recent 
statement number entry in the 
adcon table (XREF buffer) if the 
statement number reference being 
processed by LABTLU-IEKCLT is not 
a definition of a statement numb- 
er. Word 5 is not used for state- 
ment number entries that corres- 
pond to definitions of statement 
numbers. 


Word 6 - Bytes 1 and 2 - The number of 
times the XREF buffer has been 
written on SYSUT2 at the time the 
statement number entry is pro- 
cessed by LABTLU-IEKCLT. 


Bytes 3 and 4 - A pointer to the 
first XREF buffer entry for the 
statement number. 


Word 7 - Contains an ISN if the reference 
is to a definition of a statement 
number; contains -1 if the state- 
ment number has been previously 
defined. 


Word 9 - Statement number sequence chain 
field. 


CSORN-IEKCCR processes symbols for XREF 
much the same way as LABTLU-IEKCLT pro- 
cesses Statement numbers. However, for 
symbols, no processing is required for 
definitions and there is no sequencing. 


CSORN-IEKCCR adds one word to the dic- 
tionary entries for variables making a 
total of ten words in each entry. Word 10 
for a variakle entry is used in the same 
way as word 6 for a statement number entry. 
The first half of word 10 indicates the 
number of times the buffer has been written 
on SYSUT2 at the time the variable entry is 
processed by CSORN-IEKCCR. The second half 
of word 10 contains a pointer to the first 
XREF buffer entry for the symbol. The 
first half of word 8 is used as a pointer 
to the last (most recent) XREF buffer entry 
for the symbol. 


Subroutine IEKXRS is also used during 
symbol processing to write the XREF buffer 
out on SYSUT2 whenever the Luffer becomes 
full. 


XREF Processing 


If the XREF option is selected, the FSD 
calls XREF-IEKXRF after the completion of 
STALL-IEKGST processing and before phase 
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15. XREF-IEKXRF is a separate overlay seg- 
ment that overlays phase 10 and is overlaid 
by phase 15. 


XREF-IEKXRF reads from SYSUT2 all buff- 
ers that were written out by IEKXRS during 
LABTLU-IEKCLT and CSORN-IEKCCR procesSing. 
It then sets up linkage between buffers for 
the symbol or statement number to create 
one sequential chain of ISNs and writes out 
the symbol or statement number with its 
ISNS on SYSPRINT. This process continues 
until all symbols and statement numbers 
with their ISNs are written on SYSPRINT. 
Control is then returned to the FSD which 
calls phase 15. 


PHASE 15 


Before phase 15 gains control, phase 10 
has read the source statements, built the 
information table, and restructured the 
source statements into operator-operand 
pairs. When given control, phase 15 trans- 
lates the text of arithmetic expressions, 
gathers information about branches and 
variables, converts phase 10 data text toa 
new text format, assigns relative addresses 
to constants and variables, and generates 
address constants when needed, to serve as 
address references. Thus, phase 15 modi- 
fies and adds to the information table and 
translates phase 10 normal and data text to 
their phase 15 formats. 


Phase 15 is divided into two overlay 
segments, PHAZ15, and CORAL. Chart 05 
Shows the overall logic of the phase. 


PHAZ15 translates and reorders the text 
entries for arithmetic expressions from the 
operator-operand format of phase 10 to a 
four-part form suitable for phase 20 pro- 
cessing. The new order permits phase 25 to 
generate machine instructions in the 
correct sequence. PHAZ15 blocks the text 
and collects information describing the 
blocks. The information, needed during 
phase 20 optimization, includes tables on 
branching locations, and on constant and 
variable usage. 


CORAL, the second overlay segment of 
phase 15, performs four functions. It 
first converts phase 10 data text to a form 
more easily evaluated by subroutine DATOUT- 
IEKTDT. CORAL then assigns relative 
addresses to all variables, constants, and 
arrays. During one phase of relative 
address assignment, CORAL rechains phase 15 
data text in order to simplify the genera- 
tion of text card images by subroutine 
DATOUT-IEKTDT. CORAL also assigns address 
constants, when needed, to serve as address 
references for all operands. 
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PHAZ15 PROCESSING 


The functions of PHAZ15 are text Llock- 
ing, arithmetic translation, information 
gathering, and reordering of the statement 
number chain. Information gathering occurs 
only if optimization (either intermediate 
or complete) has been selected; it takes 
place concurrently with text blocking and 
arithmetic translation during the same scan 
of intermediate text. Reordering of the 
Statement number chain occurs after PHAZ15 
has completed the blocking, arithmetic 
translation, and information gathering. 


PHAZ15 divides intermediate text into 
blocks for convenience in obtaining infor- 
Mation from the text. Each block begins 
with a statement number definition and ends 
with the text entry just preceding the next 
statement number definition. An attempt is 
made to limit blocks to less than 100 text 
items as an aid to register routines in 
phase 20. PHAZ15 records information 
describing a text block in a statement 
number text entry and in an information 
table statement number entry. 


During the same scan of text in which 
bklocking occurs, PHAZ15 translates arith- 
metic expressions. The conversion is from 
the operation-operand pairs of phase 10 to 
a four part format (phase 15 text). The 
new format follcws the sequence in which 
algekraic operations are performed. In 
general, phase 15 text is in the same order 
in which phase 25 will generate machine 
instructions.1 PHAZ15 copies, unchanged 
into the text area, phase 10 text that does 
not require arithmetic translation or other 
Special handling. 


During the building of phase 15 text for 
a given block (if optimization has been 
selected) , PHAZ15 constructs tables of 
informaticn on the use of constants and 
variables in that text block. It stores 
information on variakles and constants that 
are used within a block, and variables that 
are defined within a block. If OPT=2 
optimization has been selected, FPHAZ15 also 
gathers information on variables not first 
used and then defined. The foregoing usage 
information is recorded in the statement 
number text for each block for later use by 
phase 20. 


Concurrently with text blocking, arith- 
metic translation, and gathering of 
constant/variable usage information, PHAZ15 
discovers branching text entries and reco- 
rds the branching or connection informa- 
tion. This information, consisting ini- 
tially of a table of branches from each 
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Em i optimization is selected, phase 20 may 
further manipulate the phase 15 text. 


text block (forward connections), is stored 
in a special array. Branching (connection) 
information is used during phase 20 
optimization. 


After PHAZ15 has completed the previous- 
ly mentioned processing, it reorders the 
statement number chain of the information 
table. The original order of statement 
numbers, aS phase 10 recorded them, was in 
order of their occurrence in source state- 
ments as either definitions™t or operands. 
The new sequence after phase 15 reordering 
is according to source statement occurrence 
as definitions only. The new order is 
established to facilitate phase 20 
processing. 


Lastly, PHAZ15 acquires a table of back- 
ward connection information consisting of 
branches into each statement number, or 
text block. PHAZ15 derives this informa- 
tion from the forward connection informa- 
tion it previously obtained. Thus, connec- 
tion information is of two types, forward 
and backward. PHAZ15 records a table of 
branches from each text block and a table 
of branches into each text block. Connec- 
tion information of both types is used dur- 
ing phase 20 optimization. 


Charts 06, O07, and 08 depict the flow of 
control during PHAZ15 execution. 


Text Blocking 


During itS Scan and conversion of phase 
10 text, PHAZ15 sections the module into 
text blocks, which are the basic units upon 
which the optimization and register assign- 
ment processes of phase 20 operate. A text 
block is a series of text entries that 
begins with the text entry for a statement 
number and ends with the text entry that 
immediately precedes the text entry for the 
next statement number. (The statement 
number may be either programmer defined or 
compiler generated.) When PHAZ15 encoun- 
ters a statement number definition (i.e., 
the phase 10 text entry for a statement 
number) it begins a text block. It does 
this by constructing a statement number 
text entry (refer to Appendix B, “Phase 15 
Intermediate Text Modifications"). PHAZ15 
also places a pointer to the statement 
number text entry into the statement number 
entry (information table) for the asso- 
Ciated statement number. 


PHAZ15 resumes itsS Scan and converts the 
phase 10 text entries following the state- 
ment number definition to their phase 15 
formats. After each phase 15 text entry is 
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1K statement number occurs as a definition 
when that statement number appears to the 
left of a source statement. 
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formed and chained into text, PHAZ15 places 
a pointer to that text entry into the 
BLKEND field of the previously constructed 
Statement number text entry. This field is 
thereby continually updated to point to the 
last phase 15 text entry. 


When the next statement number defini- 
tion is encountered, PHAZ15 begins the next 
text block in the previously described 
manner. A pointer to the text entry that 
ends the preceding block has already been 
recorded in the BLKEND field of the state- 
ment number text entry that begins that 
block. Thus, the boundaries of a text 
block are recorded in two places: the 
beginning of the block is recorded in the 
associated statement number entry (informa- 
tion table); the end of the block is 
recorded in the BLKEND field of the asso- 
Ciated statement number text entry. All 
text blocks in the module are identified in 
this manner. 


Note: For each ENTRY statement in the 
source module, phase 10 generates a state- 
ment number text entry and places it into 
text preceding the text for the ENTRY 
statement. Phase 10 also ensures that the 
statement following an ENTRY statement has 
a statement number; if a statement number 
is not provided by the programmer, phase 10 
generates one. The text entries for each 
ENTRY statement therefore form a separate 
text block, which is referred to as an 
entry block. 


Figure 3 illustrates the concept of text 
blocking. In the figure, two-text blocks 
are shown: one beginning with statement 
number 10; the other with statement number 
20. The statement number entry for state- 
ment number 10 contains a pointer to the 
statement number text entry for statement 
number 10, which contains a pointer to the 
text entry that immediately precedes the 
statement number text entry for statement 
number 20. Similar pointers exist for the 
text block starting with statement number 
20. 


Arithmetic Translation 


Arithmetic translation is the reordering 
of arithmetic expressions in phase 10 text 
format to agree with the order in which 
algekraic operations are performed. Arith- 
metic expressions may exist in IF, CALL, 
and ASSIGN statements and I/O data-list, as 
well as in arithmetic statements and state- 
ment functions. 


When PHAZ15 detects a primary adjective 
code for a statement that needs arithmetic 
translation, it passes control to the 
arithmetic translator (ALTRAN-IEKJAL). 
the phase 10 text for the statement does 
not require any type of special handling, 


If 


Discussion of Major Components 27 


Statement Number Entry for 
Statement Number 10 


Statement Number Entry for 
Statement Number 20 
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* LDF is the mnemonic for the statement number operator 


Figure 3. Text Blocking 


ALTRAN-IEKJAL reorders it into a series of 
phase 15 text entries that reflect the 
sequence in which arithmetic operations are 
to be carried out. During the reordering 
process, ALTRAN-IEKJAL calls various sup- 
porting routines that perform checking and 
resolution (e.g., the resolution of opera- 
tions involving operands of different 
modes) functions. 


Throughout the reordering process, 
ALTRAN-IEKJAL is checking for text that 
requires special handling before it can be 
placed into the phase 15 text area. (Spe- 
cial handling is required for complex 
expressions, terms involving unary minuses 
(e.g., A=-B), subscript expressions, state- 
ment function references, etc.) If Special 
text processing is required, ALTRAN-IEKJAL 
calls one or more subroutines to perform 
the required processing. 


During reordering and, if required, spe- 
cial handling, subroutine GENER-IEKLGN is 
called to format the phase 15 text entries 
and to place them into the text area. 


REORDERING ARITHMETIC EXPRESSIONS: The 
reordering of arithmetic expressions is 
done by means of a pushdown table. This 
table is a last-in, first-out list. After 
the table iS initialized (i.e., the first 
operator-operand pair of an arithmetic 
expression is placed into the table), the 
arithmetic translator (ALTRAN-IEKJAL) com- 
pares the operator of the next operator- 
operand pair (term) in text with the opera- 
tor of the pair at the top of the pushdown 
table. As a result of each comparison, 
either a term is transferred from phase 10 
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the top 


PHASE 15 TEXT 

















text to the table, or an operator and two 
operands (triplet) are brought from the 
table to the phase 15 text area, eliminat- 
ing the top term in the pushdown table. 


The comparison made to determine whether 
a term is to be placed into the pushdown or 
whether a triplet is to be taken from the 
pushdown is always between the operator of 
a term in phase 10 text and the operator of 
the top term in the table. Each comparison 
is made on the basis of relative forcing 
strength. A forcing strength is a value 
asSigned to an operator that determines 
when that operator and its associated 
operands are to be placed in phase 15 text. 
The relative values of forcing strengths 
reflect the hierarchy of algebraic opera- 
tions. The forcing strengths for the 
various operators appear in Table 2. 


When the arithmetic translator (ALTRAN- 
IEKJAL) encounters the first operator- 
operand pair (phase 10 text entry) of a 
statement, the pushdown table is empty. 
Since the translator cannot yet make a con- 
parison between text entry and table ele- 
ment, it enters the first text entry in the 
tor position of the table. The translator 
then compares the forcing strength of the 
operator of the next text entry with that 
of the table element. If the strength of 
the text operator is greater than that of 
(and only) table element, the text 
entry (operator-operand pair) becomes the 
top element of the table. The original tor 
element is effectively “pushed down" to the 
next lower position. In Figure 4, the 
number-1 section of the drawing shows the 
pushdown table at this time. 


Table 2. Operators and Forcing Strengths 
ee ee Se saa el 1 
| Forcing | 
| Operator {| Strength (| 
~---~------------------------4-------=----| 
[End Mark | 1 | 
= | 2 | 
l) | 3 | 
|, | 6 | 
| .OR. | 7 | 
| AND. | 8 | 
| NOT. | 9 | 
}.EQO., -NE., | 10 | 
LeaGls-, «LT. | | 
|.GE., LE. | | 
|+, -, minus ( | 11 | 
[*5. -7 | 12 | 
| #* | 13 | 
| (£ --left parenthesis after | 14 | 
| a function name { | 
| (s --left parenthesis after | 15 | 
| an array name | | 
| ( | 16 | 
esas ee HC et eS er POE 4 


The operator of the next text entry 
(operator C--operand C at section 2) is 
compared with the top table element (opera- 
tor B--operand B at section 1) in a similar 
manner. 


When a comparison of forcing strengths 
indicates that the strength of the text 
operator (operator C, section 2), is less 
than or equal to that of the top table ele- 
ment (operator B), the table element is 
said to be “forced.“ The forced operator 
(operator B) is placed in the new phase-15 
text entry (section 3 of the figure) with 
its operand (operand B) and the operand of 
the next lower table entry (operand A). 
Note that ALTRAN-IEKJAL has generated a new 
operand t (see section 3) called a “tem- 
porary." A temporary is a compiler- 


1. Text in Pushdown Table 


Top Element 





Op B Oprnd B 
Op A Oprnd A 


4, New Top Element of Pushdown 


NOTE: A phase 15 text entry having an arithmetic operator may be envisioned 
operand 1 = operand 2 - operator - operand 3, where the equal sign is 


We 


Op A 


Figure Text Reordering Via the Pushdow 


generated operand in which a preliminary 
result may be held during object-module 
execution.’ With operator B, operand B, and 
operand A (a triplet) removed from the 
pushdown table, the previously entered 
operator-operand pair (operator A, section 
1) now becomes the top element of the takle 
(section 4). ALTRAN-IEKJAL assigns the 
previously generated temporary t as the 
operand of this pair. This temporary 
represents the previous operation (operator 
B--operand A--operand B). 


Comparisons and text-to-table exchanges 
continue, a higher strength text operator 
"“pushing™ a phase 10 text entry into the 
table and a lower strength text operator 
"forcing™ the top table operator and its 
operands (triplet) from the table. In each 
case, the forced takle items Lecome the new 
phase 15 text entry. An exception to the 
general rule is a left parenthesis, which 
has the highest forcing strength. Opera- 
tors following the left parenthesis can be 
forced from the table only by a right 
parenthesis, although the intervening 
Operators (between the parentheses) are of 
lower forcing value. When the translator 
reaches an end mark in text, its forcing 
strength of 1 forces all remaining elements 
from the takle. 


SPECIAL PROCESSING OF ARITHMETIC EXPRES- 
SIONS: As stated before, arithmetic trans- 
lation involves reordering a group of phase 
10 text entries to produce a new group of 
phase 15 text entries representing the same 
source statement. Certain types of 
entries, however, need special handling 
(for example, subscripts and functions) . 
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1A given temporary may be eliminated by 
phase 20 during optimization. 


2. Phase 10 Text Entries 


Opc Oprnd C 
Op D Oprnd D 


3. New Phase 15 Text Entry 


Operator Operand 1 Operand 2 Operand 3 






Current phase 10 text entry 


Next phase 10 text entry 


as 
implied. 


n Table 
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When it has been determined that special 
handling is needed, control is passed to 
one or more other subroutines (refer to 
Chart 07) that perform the desired 
processing. 


The following expressions and terms need 
special handling before they are placed in 
phase 15 text: complex expressions, terms 
involving a unary minus, terms involving 
powers, commutative expressions, subscript 
expresSions, subroutine or function subpro- 
gram references, statement function 
references, and expressions involved in 
logical IF statements. 


Complex Expressions: A complex expression 
is converted into two expressions, a real 


expression and an imaginary one. For real 
elements in the expression, complex tem- 
poraries are generated with zero in the 
imaginary part and the real element in the 
real part. For example, the complex 
expression B + C + 25. is treated as: 


SPs pe ie ge PT a ee ee a 
| B + C + 25% 
[ real real real | 
| ---------------------------------~------- { 
| B + Cc + QO. | 
| imag imag imag | 
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An expression is not treated as complex 
if the “result" operand (left of the equal 
Sign in the source statement) is real. In 
this case, the translator places only the 
real part of the expression in phase 15 
text. But if a complex multiplication, 
division, or exponentiation is involved in 
the expression, the real and imaginary 
parts will appear in phase 15 text, put 
only the real part of the result wili be 
used at execution time. 


Terms Containing a Unary Minus: In terms 
that contain unary minuses, the unary 


minuses are combined with additive opera- 
tors (+,-) to reduce the number of ofpera- 
tors. This combining, done by subroutine 
UNARY-IEKKUN, may result in reversed opera- 
tors or operands or both in phase 15 text. 
For example, -(B-C) becomes C-B, and At (-B) 
becomes A-B. This process reduces the 
number of machine instructions that phase 
25 must generate. 


Operations Involving Powers: Several kinds 
of special handling are provided by sukrou- 


tine UNARY-IEKKUN for operations involving 
powers. Multiplications by powers of two 
are converted to left shift operations. A 
constant integer power of two raised toa 
conStant integer power is converted to the 
equivalent left shift operation. Lastly, a 
constant or variable raised to a constant 
integer power is converted to a series of 
multiplications (and a division into one, 
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if necessary). This conversion is a func- 
tion of the level of optimization selected. 
This handling requires less execution time 
than using an exponentiation subroutine. 


Commutative Operations: If an oferation is 
commutative (either operand can ke operated 


upon, Such as in addition or multiplica- 
tion), the two operands are reordered to 
agree with their absolute locations in the 
dictionary. 


Subscripts: Subroutines SUBMULT-IEKKSM and 
SUBACD-IEKKSA perform subscript processing. 
Subscripted items are processed one at a 
time throughout the subscript. If the sub- 
Script itself is an expression, it is first 
processed via the translator. Text entries 
are then generated to multiply the sub- 
Script variakle by the dimension factor and 
length. Each subscript itém is handled in 
a Similar manner. When all subScript items 
have been processed, phase 15 text entries 
are generated to add all subscript values 
together to produce a single subscript 
value. 


In general, during compilation, con- 
stants in subScript expressions are combi- 
ned, and their composite value is placed in 
the displacement field of the phase 15 text 
entry for the subscript item. (Refer to 
Appendix B, “Phase 15/Phase 20 Intermediate 
Text Modifications.") Phase 25 uses the 
value in the displacement field to gener- 
ate, in the resultant object instructions, 
the displacement for referring to the ele- 
ments in the array. This combining of con- 
stants reduces the number of instructions 
needed during execution to compute the sub- 
Script value. 


Expressions Referring to In-Line Routines 
or Sukprograms: Expressions containing 


references to in-line routines or sukpro- 
grams are processed by the following suk- 
routines: FUNDRY-IEKJFU, BLTNFN-IEKJBF, 
and DFUNCT-IEKJDF. 


Arguments that are expressions are 
reduced by the translator to a single tem- 
porary, which is used as the argument. If 
an argument is a sukscripted variable, sub- 
Script processing (previously discussed) 
reduces the subscript to a single sub- 
Scripted item. Either subroutine DFUNCT- 
IEKJDF (for references to library routines) 
or Subroutine BLTNFN-IEKJBF (for references 
to in-line routines) then conducts a series 
of tests on the argument and performs the 
processing determined by the results of the 
tests. 


If a function is not external and is in 
the subprogram table (IEKLFT) (refer to 
Appendix A, “Subprogram Table"), it is 
determined if the required routine is in- 
line. Then the mode is tested. If the 


routine is in-line and the mode is as 
expected, BLTNFN-IEKJBF either generates 
text or substitutes a special operator 
(such as those for ABS or FLOAT) in the 
phase 15 text so that phase 25 can later 
expand the function. Phase 15 provides 
some in-line routines itself. Instead of 
placing a special operator in text, phase 
15 inserts a regular operator, such as the 
Operator for AND or STORE. 


If the mode and/or number of arguments 
in an in-line function is not as expected, 
the function is assumed to be external. 


If the mode and/or number of arguments 
in a library function is not as expected, 
another test is performed. The test deter- 
mines if a previous reference was made 
correctly for these arguments. If the pre- 
vious reference was aS expected, it is 
assumed that an error exists. Otherwise, 
the function is assumed to be external. 


If a function is assumed to be external 
(either used in an EXTERNAL statement or 
does not appear in the subprogram table), 
text is generated to load the addresses of 
any arguments that are subscripted 
variables into a parameter list in the 
adcon table. (If none of the arguments are 
subscripted variables, the load address 
items are not required.) A text entry for 
a subroutine or a function call is then 
generated. The operator of the text entry 
is for an external function or subroutine 
reference. The entry points to the dic- 
tionary entry for the name. The text 
representation of the argument list is then 
generated and placed into the phase 15 text 
chain. 


If a function is not external, is in the 
subprogram table, but does not represent an 
in-line routine, text is generated to load 
the addresses of any arguments that are 
subscripted variables into a parameter list 
in the adcon table. (Load address items 
are not required if none of the arguments 
are subscripted variables.) A text entry 
having a library function operator is | 
generated. This entry points to the dic- 
tionary entry for the function. The text 
representation of the argument list is then 
generated and placed into the phase 15 text 
chain. 


Parameter List Optimization: Subroutine 
DFUNCT-IEKJDF performs parameter list opti- 


mization. If two or more parameter lists 
are identical, all but one can be eli- 
minated. Likely candidates for optimiza- 
tion are those parameter lists with (1) the 
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TBLTNFN-IEKJBF expands the following func- 
tions: TBIT, LAND, LOR, LXOR, ADDR, SNGL, 
REAL, AIMAG, DCMPLX, DCONJG, and CONJG. 


same number of parameters and 
nonzero parameters. When two such lists 
are found, individual parameters are com- 
pared to determine of the lists are actual- 
ly identical or merely of the same format. 


(2) the same 


To make the comparison eaSier, the 
Parameter List Optimization Table is for- 
med. Its format is: 


| Number of | Number of | Pointer jPointer | 
| parareters|nonzero |to NADCON|to next | 
Jain list |parameters|table Jentry of | 
| Jin list jentry Jlike for-| 
| | | [mat in | 
| | [this | 
| | | [table | 
}---------- }---------- $---------4--------- 

| 1kyte | 1 byte | 1 Eyte | 1 byte | 
a a ee pipe rere neers: oat as te J 


For each unique parameter list, an entry is 
made in the table describing the number of 
parameters in the list, the numker of non- 
zero zero parameters in the list, a pointer 
to the adcon table (refer to Appendix A: 
"NADCON Table") and a pointer to the next 
parameter 1ist optimization table entry 
that contains a like parameter list format, 
but unlike individual parameters. Whena 
new parameter list is generated, the paran- 
eter list optimization table is scanned for 
a possible identical list. If one is 
found, the parameters in the new list are 
compared with the parameters in the old 
list. If the lists are identical, a point- 
er to the old list is used as the new 
list's pointer. If the lists are not 
identical, an entry for the new list is 
made in the table and chained to the last 


like (in format) entry. For example: 
es ae IN a ee a = 
aunwer of i Nunber of | NADCON (peineer to 

| rarareters|nonzero [Table |next entry 


| 

Os | 

| | |parameters|pointer|of like | 
| 


|format 





} 10 | 7 | | 
}---------- }---------- $------- $----------- 1] 
| 30 | 25 { | 
20 | 16 
ga pa A a a aes Es ee in 
10 | 7 } | ——# | 
20 16 | 
|~--------- }---------- $---~--- $----------- 
| | | | | 
| | | | | 
30S | | 
Po Se a ees Sp ay eas A eee Ueno Era pee mee ea J 
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Parameter list optimization is limited 
to (1) 100 entries in the parameter list 
optimization table or (2) 255 entries in 
the adcon table. No further parameter list 
optimization is attempted if either limit 
is exceeded. 


Expressions Containing Statement Function 
References: For expressions containing 


Statement function references, the argu- 
ments of the statement function text are 
reduced to Single operands (if necessary). 
These arguments and their mode are stored 
in an argument save table (NARGSV), which 
serves aS a dictionary for the statement 
function skeleton pointed to by the dic- 
tionary entry for the statement function 
name. The argument save table is used in 
conjunction with the usual pushdown proce- 
dure to generate phase 15 text items for 
the statement function reference. When the 
translator encounters an operand that is a 
dummy argument, the actual argument corre- 
sponding to the dummy is picked up from the 
argument save table and replaces the dummy 
argument. 


Logical Expressions: Subroutines ALTRAN- 
IEKJAL, ANDOR-IEKJAN, and RELOPS-IEKKRE 
perform a special process, called anchor 
point, on logical expressions containing 
relational operators, ANDsS, ORS, and NOTs, 
so that, at object time, unnecessary logic- 
al tests are eliminated. With anchor-point 
“optimization,” only the minimum number of 
object-time logical tests are made before a 
branch or falil-through occurs. For 
example, with anchor-point handling, the 
statement IF (A-AND.B.AND.C) GO TO 500 will 
produce (at object time) a branch to the 
next statement if A is false, because B and 
C need not be tested. Thus, only a minimum 
number of operands will be tested. Without 
anchor-point handling of the expression 
during compilation, all operands would be 
tested at object time. Similar special 
handling occurs for text containing logical 
ORS. 


When a primary adjective code for a log- 
ical IF statement or an end-of-DO IF is 
placed in the pushdown table, a scan of 
phase 10 text determines if the associated 
Statement can receive anchor-point hand- 
ling. The statement can receive anchor- 
point handling if two conditions are met. 
There must not be a mixture of ANDs and ORs 
in the statement. A logical expression, if 
it is in parentheses, must not be negated 
by the NOT operator. If these two condi- 
tions are not met, special handling of the 
logical expression does not occur. 


Gathering Constant/Variable Usage 
Information 


During the conversion of the phase 10 
text entries that follow the beginning of a 
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text block (i.e., the text entries that 
follow a statement number definition) to 
phase 15 format, the PHAZ15 subroutine 
MATE-IEKLMA gathers usage information for 
the variables and constants in that block. 
This information is required during the 
processing of the optimized path through 
phase 20 (refer to “Phase 20"). If opti- 
mized processing is not selected, this 
information is not compiled. Subroutine 
MATE-IEKLMA records the usage information 
in three fields (MVS, MVF, and MVX), each 
128 bits long, of the statement number text 
entry for the block (refer to Appendix B, 
"Phase 15 Intermediate Text Modifica- 
tions"). The MVS field indicates which 
variables are defined (i.e., appear in the 
Operand 1 position of a text entry) within 
the text of the block. The MVF field indi- 
cates which variables, constants, and base 
variables (refer to CORAL PROCESSING, 
"Adcon and Base Variable Assignment") are 
used (i.e., appear in either the operand 2 
or operand 3 position of a text entry) 
within the text of the block. The MVX 
field indicates which variables are defined 
but not first used (not busy-on-entry) 
within the text of the block. MVX informa- 
tion is gathered for the second level of 
optimization only. 


Subroutine MATE-IEKLMA records the usage 
information for a variable or constant at a 
specific bit location within the three 
fields. (Base variables are processed dur- 
ing CORAL processing.) The bit location at 
which the usage information is recorded is 
determined from the coordinate assigned to 
the variable or constant by subroutine 
IEKKOS. 


After a phase 15 text entry has been 
formed, subroutine MATE-IEKLMA is given 
control to determine and record the usage 
information for the text entry. It 
examines the text entry operands in the 
order: operand 2, operand 3, operand 1. 

If operand 2 has not been assigned a coor- 
dinate, subroutine MATE-IEKLMA assigns it 
the next coordinate, enters the coordinate 
number into the dictionary entry for the 
operand, and places a pointer to that dic- 
tionary entry into the MVD table entry 
associated with the assigned coordinate 
number. After MATE-IEKLMA has assigned the 
coordinate, or if the operand was previous- 
ly assigned a coordinate, it records the 
usage information for the operand. The 
operand's associated coordinate bit in the 
MVF field (of the statement number text 
entry for the block containing the text 
entry under consideration) is set on, indi- 
cating that the operand is used in the 
block. MATE+~IEKLMA executes a Similar pro- 
cedure to process operand 3 of the text 
entry. 


If operand 1 of the text entry has not 
been assigned a coordinate, MATE-IEKLMA 
assigns it the next and records the follow- 
ing usage information for operand 1: 


e Its associated coordinate bit in the 
MVX field is set on only if the asso- 
ciated coordinate bit in the MVF field 
is not on. (If the associated MVF bit 
is on, operand 1 of the text entry was 
previously encountered in the block as 
a use and therefore is not not 
busy-on-entry.) 


e Its associated coordinate bit in the 
MVS field is set on, indicating that it 
is defined within the block. 


This process is repeated for all the 
phase 15 text entries that are formed fol- 
lowing the construction of a statement 
number text entry and preceding the con- 
struction of the next statement number text 
entry. When the next statement number text 
entry is constructed, all the usage infor- 
mation for the preceding block has been 
recorded in the statement number text entry 
that begins that block. The same procedure 
is followed to gather the usage information 
for the next text block. 


Gathering Forward Connection Information 


An integral part of the processing of 
PHAZ15 is the gathering of forward connec- 
tion information, which indicates which 
text blocks pass control to which other 
text blocks. Forward connection informa- 
tion is used during phase 20 optimization. 


Forward connection information is reco- 
rded ina table called RMAJOR. Each RMAJOR 
entry iS a pointer to the statement number 
entry associated with a statement number 
that is the object of a branch or a fall- 
through. Because each statement number 
entry contains a pointer to the text block 
beginning with its associated statement 
number (refer to "Text Blocking"), each 
RMAJOR entry points indirectly to a text 
block. 


For each new text block, PHAZ15 places a 
pointer to the next available entry in RMA- 
JOR into the forward connection field of 
the associated statement number entry 
(refer to Appendix A, “Statement Number/ 
Array Table"). The statement number entry 
associated with the text block therefore 
points to the first entry in RMAJOR in 
which the forward connection information 
for that block is to be recorded. 


After starting a text block, PHAZ15 con- 
verts the phase 10 text following the 
Statement number definition to phase 15 
text. AS each phase 15 text entry is for- 
med, it is analyzed to determine if it isa 
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GO TO or compiler generated branch. If it 
is either, a pointer to the statement num- 
ker entry for each statement number that 
may be branched to as a result of the 
execution of the GO TO or generated branch 
is recorded in the next available entry in 
RMAJOR. (If two or more branches to the 
same statement number appear in the text 
following a statement number definition and 
before the next, only one entry is made in 
RMAJCR for the statement number to be 
bkranched to.) 


When PHAZ15 encounters the next state- 
ment number definition, it starts a new 
block. If the new Llock is an entry Llock, 
PHAZ15 saves a pointer to its associated 
Statement number entry for subsequent use 
and processes the text for the block. 


If the new block is neither an entry 
block nor an entry point (1.e., a block 
immediately following an entry block), 
PHAZ15 records the fall-through connection 
information (if any) for the previous 
block. If the previous block is terminated 
by an unconditional branch, it does not 
fall-through to the new block. If the pre- 
vious block can fall-through to the new 
block, PHAZ15 records a pointer to the 
statement number entry for the new block in 
the next location of RMAJOR. It then flags 
this as the last forward connection for the 
previous Llock. 


If the new Llock is an entry point 
(i1.e., a block immediately following an 
entry block) , PHAZ15 records the fall- 
through connection (if any) for the pre- 
vious non-entry block. It does this in the 
Manner described in the previous paragraph. 
It then records the forward connection 
information for all intervening entry 
blocks (1.e., entry blocks between the pre- 
vious non-entry block and the new block). 
(PHAZ15 has saved pointers to the statement 
number entries for all intervening entry 
blocks.) Each such entry block passes con- 
trol directly to the new block and there- 
fore has only one forward connection. To 
record the forward connection information 
for the intervening entry blocks, PHAZ15 
places a pointer to the next available 
entry in RMAJOR into the forward connection 
field of the statement number entry for the 
first intervening entry block. In this 
RMAJOR entry, PHAZ15 records a pointer to 
the statement number entry for the new 
block. It flags this entry as the last, 
and only, RMAJOR entry for the entry block. 
PHAZ15 repeats this procedure for the 
remaining intervening entry blocks (if 
any). PHAZ15 then proceeds to process the 
new text block. 


When all the connection information for 


a block has been gathered, each RMAJOR 
entry for the block, the first of which is 
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pointed to by the statement number entry 
for the block and the last of which is 
flagged as such, points indirectly to a 
block to which that block may pass control. 


Figure 5 illustrates the end result of 
gathering forward connection information 
for sample text blocks. Only the forward 
connection information for the blocks 
beginning with statement numbers 10 and 20 
is shown. In the figure, it is assumed 
that: 


e The block started by statement number 
10 may branch to the blocks started by 
Statement numbers 30 and 40 and will 
fali-through to the block started by 
statement number 20 if neither of the 
branches is executed. 

e The block started by statement number 
20 may branch to the blocks started by 
statement numbers 40 and 50 and will 
fali-through to the block started by 
statement number 30 if neither of the 
branches is executed. 


Reordering the Statement Number Chain 


After text blocking, arithmetic transla- 
tion, and, if complete optimization has 
been specified, the gathering of constant/ 


Statement Number Entry for 10 


Statement Number Entry for 20 


Forward Connection Information 


Figure 5. 
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variable usage information have heen con- 
pleted, subroutine PHAZ15-IEKJA reorders 
the statement number chain of the informa- 
tion table (refer to Appendix A, “Informa- 
tion Table"). The original order of the 
entries in this chain, as recorded by phase 
10, was in the order of the occurrence of 
their associated statement numbers as 
either definitions or operands. The new 
sequence of the entries after reordering is 
according to the occurrence of their asso- 
ciated statement numbers as definitions 
only. 


Although the actual reordering takes 
place after the scan of the phase 10 text, 
preparation for it takes place during the 
scan. AS each statement number definition 
is encountered, a pointer to the related 
statement number entry is recorded. Thus, 
during the course of processing, a table of 
pointers to statement number entries, which 
reflects the order in which statement num- 
bers are defined in the module, is built. 
The order of the entries in this table also 
reflects the order of the text blocks of 
the module. 


After the scan, PHAZ15-IEKJA uses this 


table to reorder the statement number 
entries. It places the first table pointer 
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into the appropriate field of the communi- 
cation table (refer to Appendix A, "“Com- 
munication Table"); it places the second 
table pointer into the chain field of the 
statement number entry that is pointed to 
by the pointer in the communication table; 
it places the third table pointer into the 
chain field of the statement number entry 
that is pointed to by the chain field of 
the statement number entry that is pointed 
to by.the pointer in the communication 
table; etc. When PHAZ15-IEKJA has per- 
formed this process for all pointers in the 
table, the entries in the statement number 
chain are arranged in the order in which 
their. associated statement numbers are 
defined in the module. The new order of 
the chain also reflects the order of the 
text blocks of the module. 


Gathering Backward Connection Information 


After the statement number chain has 
been reordered, and if optimization has 
been specified, subroutine PHAZ15-IEKJA 
gathers backward connection information. 
This information indicates which text 
blocks receive control from which other 
text blocks. Backward connection informa- 
tion is used extensively throughout phase 
20 optimization. 


Subroutine PHAZ15-IEKJA uses the reor- 
dered statement number chain and the infor- 
mation in the forward connection table 
(RMAJOR) to determine the backward connec- 
tions. It records backward connection 
information in a table called CMAJOR in 
C1520-IEKJA2. Each CMAJOR entry made by 
PHAZ15-IEKJA for a particular text block 
(block I). is a pointer to the statement 
number entry for a block from which block I 
may receive control. Because each state- 
ment number entry contains a pointer to its 
associated text block (refer to "Text 
Blocking"), each CMAJOR entry for block I 
points indirectly to a block from which 
block I may receive control. 


Subroutine PHAZ15-IEKJA gathers backward 
connection information for the text blocks 
according to the order of the statement 
number chain; it first determines and 
records the backward connections for the 
text block associated with the initial 
entry in the statement number chain; it 
then gathers the backward connection infor- 
mation for the block associated with the 
second entry in the chain; etc. 


For each text block, PHAZ15-IEKJA ini- 
tially records a pointer to the next avail- 
able entry in CMAJOR in the backward con- 
nection field (JLEAD) of the associated 
statement number entry (refer to Appendix 
A, “Statement Number/Array Table"). The 
statement number entry thereby points to 
the first entry in CMAJOR in which the 
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backward connection information for the 
block is to be recorded. 


Then, to determine the backward connec- 
tion information for the block (block I), 
PHAZ15-IEKJA obtains, in turn, each entry 
in the statement number chain. (The 
entries are obtained in the order in which 
they are chained.) After PHAZ15-IEKJA has 
oktained an entry, it picks up the forward 
connection field (ILEAD) of that entry. 
This field points to the initial RMAJOR 
entry for the text block associated with 
the obtained statement number entry. 

(Recall that the RMAJOR entries for a block 
indicate the blocks to which that block may 
pass control.)  PHAZ15-IEKJA searches all 
RMAJCR entries for the Llock associated 
with the obtained entry for a pointer to 
the statement number entry for block I. If 
such a pointer exists, the text block asso- 
ciated with the oktained statement number 
entry may pass control to block I. There- 
fore, block I may receive control from that 
klock and PHAZ15-IEKJA records a pointer to 
its associated statement number entry in 
the next available entry in CMAJCR. 
PHAZ15-IEKJA repeats this procedure for 
each entry in the statement number chain. 
Thus, it searches all RMAJOR entries for 
pointers to the statement number entry for 
bklock I and records in CMAJOR a fointer to 
the statement number entry for each text 
bElock from which block I may receive con- 
trol. PHAZ15-IEKJA flags the last entry in 
CMAJOR for block I. When the statement 
number chain has been completely searched, 
PHAZ15-IFKJA has gathered all the backward 
connection information for block I. Each 
entry that PHAZ15-IEKJA has made for block 
I, the first of which is pointed to by the 
statement number entry for block I and the 
last of which is flagged, points indirectly 
to a ktlock from which block I may receive 
control. 


Subroutine PHAZ15-IEKJA gathers the 
backward connection information for all 
blocks in the above manner. When all of 
this information has been gathered, control 
is returned to the FSD, which calls CORAL, 
the second segment of phase 15. 7 


Figure 6 illustrates the end result of 
the gathering of backward connection infor- 
mation for sample text blocks. Cnly the 
backward connections for the blocks begin- 
ning with statement numbers 40 and 50 are 
Shown. In the figure, it is assumed that: 


e The “-lock started by statement number 
4Q may receive control from the execu- 
tion of branch instructions that reside 
in the Llocks started by statement num- 
bers 10 and 20 and that it may receive 
control as a result of a fall-through 
from the block started by statement 
number 30. 
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Figure 6. Backward Connection Information 


e The block started by statement number 
50. may receive control from the execu- 
tion of a branch instruction that 
resides in the block started by state- 
ment number 20 and that it may receive 
control as a result of a fall-through 
from the block started by statement 
number 40. 


CORAL PROCESSING 


CORAL, the second segment of phase 15, 
performs the following functions: 


Data text conversion 

Relative address assignment 
Data text rechaining 

Namelist statement processing 
Define File text processing 
Initial value assignment 
Adcon table space reservation 


CORAL consists of a main subroutine, 
CORAL-~IEKGCR, which controls the flow of 
Space allocation for variables, constants, 
and any adcons necessary for local 
variables, common, equivalence, and exter- 
nal references. Embedded in CORAL-~IEKGCR 
are the routines which process constants, 
local variables, and external references. 
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PHASE 15 TEXT 


CORAL-IEKGCR calls other routines in phase 
15 to accomplish various functions. These 
routines are: 


IEKGCZ which keeps track of space keing 
allocated, generates adcons needed for 
address computation in the okject 
module, rechains data text in the order 
of variakle assignment, generates 
adcons necessary for common, equiva- 
lence, and external references, and 
sets up error table entries to be used 
by phase 30 if errors occur. 


NDATA-IEKGDA which processes phase 10 
data text. 


EQVAR-IEKGEV which handles common and 
equivalence space allocation. 


NLIST-IEKTNL which processes namelist 
text. 


DFILE-IEKTDF which processes define 
file text. 


CATOUT-IEKTDT which processes data 
text. 


Chart 09 shows the overall logic flow of 
CORAL. 


Translation of Data Text 


The first section of CORAL, subroutine 
NDATA-IEKGDA, translates data text entries 
from their phase 10 format to a form more 
easily processed by another CORAL subrou- 
tine, DATOUT-IEKTDT. Each phase 10 data 
text entry (except for initial housekeeping 
entries) contains a pointer to a variakle 
or constant in the information table. Each 
variable in the series of entries is to be 
assigned to a constant appearing in another 
entry. Placed in Separate entries, vari- 
able and constant appear to be unrelated. 
In each phase 15 data text entry, after 
translation, each related variable and con- 
stant are paired (they appear in adjacent 
fields of the same entry). 


The following example shows how a series 
of phase 10 data text entries are trans- 
lated by NDATA-IEKGDA to yield a smaller 
number of phase 15 text entries, with each 
related constant and variable paired. 
Assume a statement appearing in the source 
module as DATA, A,B/2*0/. The resulting 
phase 10 text entries appear as follows 
(ignoring the chain, mode, and type fields, 
and the two initial housekeeping entries) : 


priate hag ee eg a ae Ney ep ee ee eS 1 
| Adjective | | 
| Code for: | Pointer | 
|-------------------- 4-------------------- { 
| | Pointer to A | 
| | in dictionary | 
|--------~----------- $-------------------- { 
| ; | Pointer to B | 
| | in dictionary | 
|-------------------- -------------------- { 
| / [| 2 | 
}-------------------- {-—~----------------- { 
| * | Pointer to 0 | 
| | in dictionary | 
}-------------------- 4~------------------- { 
| / | 0 | 
Cr ee ph erst fe J 


Note that the variables A and B and the 

constant value 0 appear in Separate text 
entries. The NDATA-IEKGDA translation of 
the above phase 10 entries (ignoring the 


contents of the indicator and chain fields,. 


and two optional fields needed for special 


cases) appears as follows: 

err eee ans ee eae oe marae 
|Indicator| Chain |P1 Field |P2 Field | 
}--------- +--------- 4----------}---------- { 
| | {pointer | pointer | 
| | {to A in [to 0 in | 
| | | dictionary|dictionary | 
[pe +>-------- $----------4---------- { 
| | | pointer | pointer | 
| | jto B in {to 0 in | 
| | |dictionary|dictionary | 
Canepa ene eee Heap eee yoann nae enero fee Or Se ctan 4 
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In this case, each variable and its speci- 
fied constant value appear in adjacent 
fields of the same phase 15 text entry. 
The reader should refer to Appendix B, 
"Phase 15/20 Intermediate Text Modifica- 
tion" for the detailed format of the phase 
15 data text entry and the use of the spe- 
cial fields not discussed. 


Relative Address Assignment 


The chief function of CORAL is to assign 
relative addresses to the operands (con- 
Stants and variables) of the source module. 
The addresses indicate the locations, rela- 
tive to zero, at which the operands will 
reside in the object module resulting from 
the compilation. The relative address 
assigned to an operand consists of an 
address constant and a displacement. These 
two elements, when added together, form the 
relative address of the operand. The 
address constant for an operand is the base 
address value used to refer to that operand 
in main storage. Address constants are 
recorded in the adcon table (NADCON) and 
are the elements to which the relocation 
factor is added to relocate the object 
module for execution. The displacement for 
an operand indicates the number of bytes 
that the operand is displaced from its 
associated address constant. Displacements 
are in the range of 0 to 4095 bytes. The 
relative address assigned to an operand is 
recorded in the information table entry for 
that operand in the form of: 


1. A numeric displacement from its asso- 
ciated address constant. 


2. A pointer to an information table 
entry that contains a pointer to the 
associated address constant in the 
adcon table. 


Relative addresses are assigned through 
use of a location counter. This counter is 
initially set to zero and is continually 
updated by the size (in bytes) of the 
Operand to which an address is assigned. 
The value of the location counter is used 
to: 


e Contain the displacement to ke assigned 
to the next operand. 


e Determine when the next address con- 
stant is to be established. (When the 
location counter achieves a value in 
excess of 4095, a new address constant 
is established.) 


CORAL assigns addresses to source module 
operands in the following order: 


e Constants. 


e Variables. 
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e Arrays. 


e Hollerith character strings when used 
as arguments. | 


e Equivalenced variables and arrays. 


e Common variables and arrays, including 
variables and arrays made common using 
the EQUIVALENCE statement. 


The manner in which addresses are assigned 
to each of these operand types is described 
in the following paragraphs. Because con- 
Stants, variables, and Hollerith character 
strings are processed in the same manner, 
they are described together. 


Constants, Variables, and Hollerith 


Character Strings Used as Arguments: Sub- 
routine CORAL-IEKGCR first assigns relative 


addresses to the constants of the module. 
As each constant is assigned a relative 
address, CORAL-~IEKGCR calls the FSD subrou- 
tine, IEKTLOAD, to place the constant in 
the object module in the form of TXT 
records. Addresses are then assigned to 
variables. (In the subsequent discussion, 
constants, variables, and Hollerith 
character strings are referred to collec- 
tively as operands.) The first operand is 
assigned a displacement of zero plus the 
length of the save area, parameter list, 
and branch table. Operands that are 
assigned locations within the first 4096 
bytes of the object module are not explic- 
itly assigned an address constant. Such 
operands use the base address value loaded 
into reserved register 12 as their address 
constant (refer to Phase 20, “Branching 
Optimization"). The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated by the size in bytes of the 
operand. 


The next operand is assigned a displace- 
ment equal to the current value of the 
location counter. The displacement is 
recorded in the information table entry for 
that operand. The location counter is then 
updated, and tested to see if it exceeds 
4095. If it does not, the next operand is 
processed as described above. 


If sufficient operands exist to cause 
the location counter to achieve a value in 
excess of 4095, the first address constant 
1S established. The value of this address 
constant equals the location counter value 
that caused its establishment. This 
address constant becomes the current 
address constant and is saved for subse- 
quently assigned relative addresses. The 
location counter is then reset to zero and 
the next operand is considered. 


38 


| Arrays: 


After the first address constant is 
established, it is used as the address con- 
Stant portion of the relative addresses 
assigned to subsequent operands. The dis- 
placement for these operands is equal to 
the value of the location counter at the 
time they are considered for relative 
address assignment. 


When the location counter again reaches 
a value in excess of 4095, another address 
constant is established. Its value is 
equal to the current address constant plus 
the displacement that caused the establish- 
ment of the new address constant. This new 
address constant then becomes current and 
is used as the address constant for subse- 
quent operands. The location counter is 
then reset to zero and the next operand is 
processed. This overall process is 
repeated until all operands (constant, 
variables, and Hollerith strings) are pro- 
cessed. Source module arrays are then ccn- 
sidered for relative address assignment. 


CORAL-IEKGCR then assigns each 
array of the source module that is not in 
common a relative address that is less than 
(by the span of the array) the relative 
address at which the array will reside in 
the object module. (The concept of span is 
discussed in Appendix F.) The actual rela- 
tive address at which an array will reside 
in the object module is derived from the 
sum of address constant and displacement 
that are current at the time the array is 
considered for relative address assignment. 
The array Span is subtracted from the rela- 
tive address to facilitate subscript 
calculations. 


CORAL-IEKGCR subtracts the span in one 
of two ways. If the span is less than the 
current displacement, it subtracts the span 
from that displacement, and assigns the 
result as the displacement portion of the 
relative address for the array. In this 
case, the address constant assigned to the 
array is the current address constant. If 
the span iS greater than the current dis- 
placement, CORAL-IEKGCR subtracts the span 
from the sum of the current address con- 
Stant and displacement. The result of this 
Operation is a new address constant, which 
does not become the current address con- 
Stant. CCRAL-IEKGCR assigns the new 
address constant and a displacement of zero 
to the array. It then adds the total size 
of the array to the location counter, 
obtains the next array, and tests the value 
of the location counter. If the value of 
the location counter does not exceed 4095, 
CORAL-IEKGCR does not take any additional 
action before it processes the next array. 
If the location counter value exceeds 4095, 
CORAL-IEKGCR establishes a new address ccn- 
stant, resets the location counter, and 
processes the next array. After all arrays 


have relative addresses, CORAL-IEKGCR calls 
subroutine EQVAR-IEKGEV to assign address 
to equivalence variables and arrays that 
are not in common. 


Equivalence Variables and Arrays Not in 


Common: In asSigning relative addresses to 
equivalence variables and arrays, subrou- 
tine EQVAR-IEKGEV attempts to minimize the 
number of required address constants by 
using, if possible, previously established 
address constants as the base addresses for 
equivalence elements. EQVAR-IEKGEV pro- 
cesses equivalence information on a group- 
by-group basis, and asSigns a relative 
address, in turn, to each element of the 
group. Prior to processing, EQVAR-IEKGEV 
determines the base value for the group. 
The base value is the relative address of 
the head* of the group. The base value 
equals the sum of the current address con- 
stant and displacement (location counter 
value). After EQVAR-IEKGEV has determined 
the base value, it obtains the first (or 
next) element of the group and computes its 
relative address. The relative address for 
an element equals the sum of the base value 
for the group and the offset of the ele- 
ment. The offset for an element is the 
number of bytes that the element is dis- 
placed from the head of the group (refer to 
"Common and Equivalence Processing"). 
EQOVAR-IEKGEV then compares the computed 
relative address to the previously estab- 
lished address constants. If an address 
constant exists such that the difference 
between the computed relative address and 
the address constant is less than 4095, 
EQVAR-IEKGEV assigns that address constant 
to the equivalence element under considera- 
tion. The displacement assigned in this 
case is the difference between the computed 
relative address of the element and the 
address constant. EQVAR-IEKGEV then pro- 
cesses the next element of the group. 


If the desired address constant does not 
exist, EQVAR-IEKGEV establishes a new 
address constant and assigns it to the ele- 
ment. The value of the new address con- 
stant is the relative address of the ele- 
ment. EQVAR-IEKGEV then assigns the ele- 
ment a displacement of zero, and processes 
the next element of the group. When all 
elements of the group are processed, EQVAR- 
IEKGEV computes the base value for the next 
group, if any. This base value is equal to 
the base value of the group just processed 
plus the size of that group. The next 
group is then processed. 
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1The head of an equivalence group is the 
variable in the group from which all other 
variables or arrays in the group can be 
addressed by a positive displacement. 
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Common Variakles and Arrays: Sukroutine 
EQVAR-IEKGEV considers each common block of 


the source module, in turn, for relative 
address assignment. For each common klock, 
EQVAR-IEKGEV assigns relative addresses to 
(1) the variables and arrays of that block, 
and (2) the variables and arrays equiva- 
lenced into that common block. (The pro- 
cesSing of variables and arrays equiva- 
lenced into common is described ina later 
paragrarfh.) 


Because common blocks are considered 
separate control sections, EQVAR-IEKGEV 
assigns each common block of the source 
module a relocatable origin of zero. It 
achieves the origin of zero by assigning to 
the first element of a common block a rela- 
tive address consisting of an address con- 
stant and a displacement whose sum is zero. 
For example, both the address constant and 
the displacement for the first element ina 
block can be zero. Also, the address con- 
stant can be -16 and the displacement +16. 
Note that the address constant in the lat- 
ter case iS negative. Negative address 
constants are permitted, and may be a by- 
product of the assignment of addresses to 
common variables and arrays. They evolve 
from the manner in which the relative 
addresses are assigned to arrays. A rela- 
tive address assigned to an array is equal 
to its actual relative address minus the 
Span of that array. The actual relative 
address of each array in a common block is 
equal to the offset computed for it during 
common and equivalence processing. From 
the offset of each array in the common 
block under consideration, EQVAR-IEKGEV 
Subtracts the span of that array. The 
result then replaces the previously com- 
puted offset for the array. If the result 
of one or more of these computations yields 
a negative value, EQVAR-IEKGEV uses the 
most negative as the initial address con- 
stant for the common block. It then 
assigns each element (variable or array) in 
the common block a relative address. This 
address consists of the negative address 
constant and a displacement equal to the 
aksolute value of the address constant plus 
the offset of the element. 


If the computations which subtract spans 
from offsets do not yield a negative value, 
ECVAR-IEKGEV establishes an address con- 
Stant with a value of zero as the initial 
address constant for the common block. It 
then assigns each element in the block a 
relative address consisting of the address 
constant (with zero value) and a displace- 
ment equal to the offset of the element. 


If at any time the displacement to be 
asSigned to an element exceeds 4095, EQVAR- 
TEKGEV estaklishes a new address constant. 
This address constant then bkecomes the cur- 
rent address constant and is saved for 
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inclusion in subsequently assigned 
addresses. After the new address constant 
is established, the relative address 
assigned to each subsequent element con- 
Sists of the current address constant anda 
displacement equal to the offset of that 
element minus the value of the current 
address constant. After the entire common 
block is processed, variables and arrays 
that are equivalenced into that common 
block are assigned relative addresses. 


Variables and Arrays Equivalenced into Com- 
Subroutine EQVAR-IEKGEV processes 


variables and arrays that are equivalenced 
into common in much the same manner as 
those that are equivalenced, but not into 
common. However, in this case, the base 
value for the group is zero. Only those 
address constants established for the com- 
mon block into which the variables and 
arrays are equivalenced are acceptable as 
address constants for those variables and 
arrays. 


Adcon and Base Variable Assignment: As 


CORAL establishes a new address constant 
and enters it into the adcon table, it also 
places an entry in the information table. 
This special entry, called an “adcon vari- 
able," points to the new address constant. 
All operands that have been assigned rela- 
tive addresses will have pointers to the 
adcon variable for their address constant. 
The adcon variables generated for operands 
are assigned coordinates, via MCOORD and 
the MVD table. Coordinates 81 through 128 
are reserved for base variables; however, 
some base variables may be assigned coor- 
dinates less than 81 if less than 80 coor- 
dinates are assigned during the gathering 
of variable and constant usage information. 
(Refer to PHAZ15, “Gathering Constant/ 
Variable Usage Information.") Having been 
assigned coordinates, the adcon variables 
are now called base variables. Only those 
operands receiving coordinate assignments 
are available for full register assignment 
during phase 20. 


Rechaining Data Text 


During the assignment of relative 
addresses to variables, subroutine IEKGCZ 
rechains the data text entries. Their pre- 
vious chaining (set by phase 10) was 
according to their order of appearance in 
the source program. IEKGCZ now chains the 
data text entries according to the order of 
relative addresses it assigns to variakles. 
Thus data text entries are now chained in 
the same relative order in which the 
variables will appear in the object module. 
This order simplifies the generation of 
text card images by phase 25. 
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DEFINE FILE Statement Processing 


If the source module contains DEFINE 
FILE statements, subroutine DFILE-IEKTDF 
converts phase 10 define file text to 
okject-time parameters. These parameters 
provide IHCFDIOSE with the information 
required to implement direct access READ, 
WRITE, and FIND statements. 


A parameter entry is made for each unit 
specified in a DEFINE FILE statement. This 
entry contains the unit number, the rela- 
tive address of the number of records, a 
character (‘L', ‘E', or ‘u') indicating the 
type of formatting to be used, the relative 
address of the maximum record size, an 
indicator for the size (four Lytes or two 
bytes) of the associated variable, and the 
relative address of the associated 
variable. 


DFILE-IEKTDF places the parameter 
entries along with their relative addresses 
into TXT records. It also places the rela- 
tive address of the first define file entry 
into the communication table for later use 
by phase 25. 


NAMELIST Statement Processing 


If the source module contains READ/WRITE 
statements using NAMELIST statements, sub- 
routine NLIST-IEKTNL converts phase 10 
namelist text to object-time namelist dic- 
tionaries. The object-time namelist dic- 
tionaries provide IHCFCOMH with the infor- 
Mation required to implement READ/WRITE 
statements uSing namelists (refer to Appen- 
dix A, "Namelist Dictionaries"). The dic- 
tionary developed for each list in a NAME- 
LIST statement contains the following: 


-e An entry for the namelist name. 


e Entries for the variables and arrays 
associated with the namelist name. 


e An end mark of zeros terminating the 
list. 


Each entry for a variable contains the 
name, mode, (e.g., integer*2 or real*4), 
and relative address of the variable. Both 
the address and the mode are obtained from 
the dictionary entry for the variable. 


Each entry for an array contains the 
name of the array, the mode of its ele- 
ments, the relative address of its first 
element, and the information needed to loc- 
ate a particular element of the array. 
NLIST-IEKTNL obtains the above information 
from the information table. 


NLIST-IEKTNL places the entries of the 
namelist dictionary along with their rela- 
tive addresses into TXT records. It also 


places the relative address of the begin- 
ning of the namelist dictionary into the 
address constant for the namelist name. 


Initial Value Assignment 


CORAL assigns the initial values speci- 
fied for variables and arrays in phase 15 
data text in the following manner: 


1. The relative address of the variable 
Or array to be asSigned an initial 
value or values is obtained and placed 
into the address field of a TXT 
record. 


2. Each constant (one per variable) that 
has been specified as an initial value 
for the variable or array is then 
obtained and entered into a TXT 
record. (A number of TXT records may 
be required if an array is being 
processed.) 


Such action effectively assigns the ini- 
tial value, because the relative address of 
the initial value has been set to equal the 
relative address of its associated variable 
or array element. 


Reserving Space in the Adcon Table 


After relative address assignment is 
completed, CORAL-IEKGCR calls IEKTLOAD 
IEKGCZ) to place an adcon in the object 
module for special references. CORAL- 
IEKGCR scans the operands of the informa- 
tion table to detect any of these 
references: call-by-name variables, names 
of library routines, namelist names, and 
external references. The byte-B usage 
field of each information table entry 
informs CORAL-IEKGCR if a particular 
reference belongs to one of these cate- 
gories. For each special reference that 
CORAL-IEKGCR detects, IEKGCZ calls IEKTLOAD 
to place the needed address constants in 
the reserved spaces of the object module. 


(via 


Creating Relocation Dictionary Entries 


The relocation dictionary is composed of 
entries for the address constants of the 
object module. One relocation dictionary 
entry (an RLD record) is constructed by 
CORAL-IEKGCR for each address it encoun- 
ters. If the address constant is for an 
external symbol, the RLD record identifies 
the address constant by indicating: 


e The control section to which the 
address constant belongs. 


e The location of the address constant 
within the control section. 
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e The symbol in the external symbol dic- 
tionary whose value is to be used in 
the computation of the address 
constant. 


If the address constant is for a local 
Symbol (i.e., a symbol that is located in 
the same control section as the address 
constant), the RLD record identifies the 
address constant by indicating the control 
section to which the address constant 
belongs and its location within that 
section. 


For a more detailed discussion of the 
use and format of an RLD record, refer to 


the publication IBM System/360 Operating 
System: Linkage Editor, Program Logic 


Manual. 


Creating External Symbol Dictionary Entries 


The external symbol dictionary contains 
entries for external symbols that are 
defined or referred to within the module. 
An external symbol is one that is defined 
in one module and referred to in another. 
One external symbol dictionary entry (an 
ESD record) is constructed by IEKGCZ for 
each external symbol it encounters. The 
entry identifies the symbol by indicating 
its type and location within the module. 
The ESD records constructed by IEKGCZ are: 


e ESD-0O - This is a section definition 
record and an entry point definition 
record for the source module being 
compiled. 


e ESD-2 - This record is generated for an 
external subprogram name. 


e EFSD-5 - This record iS a section 
definition record for a common block 
(either named or blank). 


For a more complete discussion of the 
use and the format of these records, refer 


to the publication IBM System/360 Operating 
System: Linkage Editor, Program Logic 


Manual. 


PHASE 20 


The primary function of phase 20 is to 
produce a more efficient object module 
(perform optimization). However, even if 
the applications programmer has specified 
no optimization, phase 20 assigns registers 
for use during execution of the object 
module. 


For a given compilation, the applica- 
tions programmer may specify CPT=0 (no 
optimization), or either of the following 
levels of optimization: OPT=1 or OPT=2. 
Thus, the functions performed by phase 20 
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depend on the optimization specified for 
the compilation. 


42 


e If no optimization (OPT=0) 


has been 
specified, phase 20 assigns to interme- 
diate text entry operands the registers 
they will require during object module 
execution (this is called basic regis- 
ter assignment). As part of this func- 
tion, phase 20 also provides informa- 
tion about the operands needed by phase 
25 to generate machine instructions. | 
Both functions are implemented in a 
Single, block-by-block, top-to-bottom 
(i.e., according to the order of the 
statement number chain), pass over the 
phase 15 text output. The end result 
of this processing is that the register 
and status fields of the phase 15 text 
entries are filled in with the informa- 
tion required by phase 25 to convert 
the text entries to machine language 
form (refer to Appendix B, “Phase 20 
Intermediate Text Modifications"). 
Basic register assignment does not take 
full advantage of the available general 
and floating-point registers, and it 
does not specify the generation of 
machine instructions that keep operand 
values in registers (wherever possible) 
for use in subsequent operations 
involving them. 


If the OPT=1 level of optimization has 
been specified, two processes are car- 
ried out: 


1. The first process, called full 
register assignment, performs the 
Same two functions as LaSic regis- 
ter asSignment. However, full 
register asSignment takes greater 
advantage of available registers 
and provides information that 
enables machine instructions to ke 
generated that keep operand values 
in registers for subsequent opera- 
tions. An attempt is also made to 
keep the most frequently used 
operands in registers throughout 
the execution of the object 
module. Full register assignment 
requires a number of passes over 
the phase 15 text. The baSic unit 
Operated upon is the text block 
(cefer to phase 15, “Text Block- 
ing"). The end result of full 
register assignment, like that of 
basic register assignment, is that 
the register and status fields of 
the phase 15 text entries are 
filled in with the information 
required by phase 25. 





2. The second process, called branch 
optimization, generates RX-format 
branch instructions in place of 
RR-format branch instructions 


wherever possible. The use of 
RX-format branches eliminates the 
need for an instruction to load 
the branch address into a general 
register. However, branch optimi- 
zation first requires that the 
sizes of all text blocks in the 
module be determined so that the 
branch address can be found. 


e If the OPT=2 level of optimization has 
keen specified, optimization is per- 
formed on a “loop-by-loop"™ basis. 
Therefore, before processing can be 
initiated, phase 20 must determine the 
structure of the source module in terms 
of the loops within it and the rela- 
tionships (nesting) among the loops. 
Then phase 20 determines the order in 
which loops are processed, beginning 
with the innermost (most frequently 
executed) loop and proceeding outward. 
The second level of optimization 
involves three general procedures: 


1. The first, called text optimiza- 
tion, eliminates unnecessary text 
entries from the loop being pro- 
cessed. For example, redundant 
text entries are removed and, 
wherever possible, text entries 
are moved to outer loops, where 
they will be executed less often. 


2. The second procedure is full reg- 
ister assignment, which is essen- 
tially the same as in the first 
level of optimization, but is more 
effective, because it is done on a 
loop-by-loop basis. 


3. The final procedure is branching 
optimization, which is the same as 
in the OPT=1 path. 


CCNTRCL FLOW 


In phase 20, control flow may take one 
of three possible paths, depending on the 
level of optimization chosen (refer to 
Chart 10). Phase 20 consists of a control 
routine (LPSEL-IEKPLS) and six routine 
groups. The control routine controls 
execution of the phase. All paths begin 
and end with the control routine. The 
first group of routines performs basic reg- 
ister assignment. This group is only 
executed in the control path for non- 
optimized processing. The second group 
performs full register assignment. Control 
passes through this group in the paths for 
both levels of optimization. The third 
group of routines performs branch optimiza- 
tion and is also used in the paths for both 
levels of optimization. The fourth group 
determines the structure of the source 
module and is used only in the path for 


OPT=2 optimization. The fifth group per- 
forms loop selection and again is only 
executed in OPT=2 optimization. The final 
group performs text optimization and is 
only used in OPT=2 optimization. 


The control routine governs the sequence 
of processing through phase 20. The pro- 
cessing sequence to be followed is deter- 
mined from the optimization level specified 
by the FORTRAN programmer. If no optimiza- 
tion is specified, the basic register 
assignment routines are brought into play. 
The unit of processing in this path is the 
text block. When all blocks are processed, 
the control routine passes control to the 
FSD, which calls phase 25. 


When OPT=1 optimization is specified, 
the control routine passes the entire 
module to the full register assignment rou- 
tines and then to the routine that computes 
the size of each text block and sets up the 
displacements required for branching opti- 
mization. Control is then passed to the 
FSD. 


When the control path for OPT=2 optimi- 
zation is selected, the unit of processing 
is a loop, rather than a block. In this 
case, the control routines initially pass 
control to the routines of phase 20 that 
determine the structure of the module. 
When the structure is determined, control 
is passed to the loop selection routines, 
to select the first (innermost) loop to be 
processed. The control routines then pass 
control to the text-optimization routines 
to process the loop. When text optimiza- 
tion for a loop is completed, the control 
routine marks each block in the loop as 
completed. This action is taken to ensure 
that the blocks are not reprocessed when a 
subsequent (outer) loop is processed. The 
control routine again passes control to the 
loop selection routines to Select the next 
loop for text optimization. This process 
is repeated until text optimization has 
processed each loop in the module. (The 
entire module is the last loop.) 


After text optimization has processed 
the entire module, the control routine 
removes the block completed marks and con- 
trol is passed to the loop selection rou- 
tines to reselect the first loop. Control 
is then passed to the full register assign- 
ment routines. When full register assign- 
ment for the loop is complete, the control 
routine marks each block in the loop as 
completed and passes control to the loop 
selection routines to select the next loop. 
This process is repeated for each loop in 
the module. (The entire module is the last 
loop.) When all loops are processed, the 
control routine passes control to the rou- 
tine that computes the size of each text 
block and sets up the displacements 
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required for branching optimization. Con- 


trol is then passed to the FSD. 
REGISTER ASSIGNMENT 


Two types of register assignment can be 
performed by phase 20: basic and full. 
Before describing either type, the concept 
of status, which is integrally connected 
With both types of assignment, is 
discussed. 


Each text entry has associated operand 
and kase address status information that is 
set up by phase 20 in the status field of 
that text entry (refer to Appendix B, 
"Phase 20 Intermediate Text Modification"). 
The status information for an operand or 
base address indicates such things as 
whether or not it iS in a register and 
whether or not it is to be retained ina 
register for subsequent use; this informa- 
tion indicates to phase 25 the machine 
instructions that must be generated for 
text entries. 


The relationship of status to phase 25 
processing is illustrated in the following 
example. Consider a phase 15 text entry of 
the form A = B+C. To evaluate the text 
entry, the operands B and C must be added 
and then stored into A. However, a number 
of machine instruction sequences could be 
used to evaluate the expression. If 
operand B iS in a register, the result can 
be achieved by performing an RX-format add 
of C to the register containing B, provided 
that the base address of C iS ina regis- 
ter. (If the base address of C is not ina 
register, it must be loaded Lefore the add 
takes place.) The result can then be 
stored into A, again, provided that the 
base address of A iS in a register. 


If both B and C are in registers, the 
result can ke evaluated by executing an 
RR-format add instruction. The result can 
then be stored into A. Thus, for phase 25 
to generate code for the text entry, it 
must have the status of operands and base 
addresses of the text entry. 


The following facts about status should 
be kept in mind throughout the following 
discussions of basic and full register 
assignment: 


1. Phase 20 indicates to phase 25 when it 
is to generate code that loads 
operands and base addresses into reg- 
isters, whether it is to generate code 
that retains operands and kase 
addresses in registers, and whether 
operand 1 is to be stored. 

2. Phase 20 makes note of the operands 
and bcase addresses that are retained 
in registers and are availakle for 
subsequent uSe. 
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Basic Register Assignment - OPT=0 


Basic register assignment involves two 
functions: assigning registers to the 
operands of the phase 15 text entries and 
indicating the machine instructions to be 
generated for the text entries. In per- 
forming these functions, basic register 
assignment does not use all of the avail- 
able registers, and it restricts the 
asSignment of those that it does use to 
special types of items (i.e., operands and 
base addresses). The registers assigned 
during basic register assignment and the 
item(s) to which each is assigned are out- 
lined in Table 3. 


Table 3. Item Types and Registers 
Assigned in Basic Register 
Assignment 

eg ge ee ene 

{Register jItem Type | 

~~-~-~---~--~--4~------------------------| 

[Floating-Point | | 

|Register | 

| {Arithmetic text entry | 
| Joperands that are real. { 
| | | 
| 2 |Imaginary part of the [ 
| {result of a complex | 
| | function. { 
| | | 
|General Purpose| 
|Register | 
| 0-1 {Arithmetic text entry | 

{ joperands that are inte- | 

| |ger, or logical operands. | 

| | | 

5 {Branch addresses and | 

| {selected logical operands | 

| | | 
| 6 | Operands that represent | 
| |index values. | 
| | 
| 7 |Base addresses | 
| | | 
| 14 | 1. Used for computed GO | 
| | TO operations. 
| {2. Logical result of | 
| | comparison opera- | 
| tions. | 
| | | 
| 15 j|Used for computed GO TO | 
| | operations. | 
L J 
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BaSic register assignment essentially 
treats System/360 as if it had a single 
branch register, a single base register, 
and a single accumulator. Thus, operands 
that are branch addresses are assigned the 
branch register, base addresses are 
assigned the base register, and arithmetic 
operations are performed uSing a Single 
accumulator. (The accumulator used depends 
upon the mode of the operands to be © 
Operated upon.) 


au 


The fact that basic register assignment 
uses a Single accumulator and a single base 
register is the key to understanding how 
text entries having an arithmetic operator 
are processed. To evaluate the arithmetic 
interaction of two operands uSing a single 
accumulator, one of the operands must be in 
the accumulator. The specified operation 
can then be performed by uSing an RX-format 
instruction. The result of the operation © 
is formed in the accumulator and is avail- 
able for subsequent use. Note that in 
operations of this type, neither of the 
interacting operands remains in a register. 


Applying this concept to the processing 
of text entries that are arithmetic in 
nature, consider that a phase 15 text entry 
representing the expression A = B + C is 
the first of the source module. For this 
text entry to be evaluated using a Single 
accumulator and base register, bLasic regis- 
ter assignment must tell phase 25 to gener- 
ate machine code that: 


e Loads the base address of B into the 
base register. 


e Loads B into the accumulator. 


e Loads the base address of C into the 
base register. (This instruction is 
not necessary if C is assigned the same 
base address as B.) 


e Adds C to the accumulator (RX-format). 


e Loads the base address of A into the 
base register (if neceSSary). 


e Stores the accumulated result in A. 


If this coding sequence were executed, 
two items would remain in registers: the 
last base address loaded and the accumu- 
lated result. These items are availakle 
for subsequent use. 


Now consider that a text entry of the 
form D= A + F immediately follows the 
akove text entry. In this case, A, which 
corresponds to the result operand of the 
previous text entry, iS in the accumulator. 
Thus, for this text entry, basic register 
assignment specifies code that: 


e Loads the base address of F into the 
base register. (If the base address of 
F corresponds to the last loaded base 
address, this instruction is not 
necesSary.) 


® Adds F to the accumulator 
add). 


(RX-format 


® Loads the base address of D into the 
base register (if necessary). 


e Stores the accumulated result in D. 


The above coding sequences are the basic 
ones specified by basic register assignment 
for arithmetic operations. The first is 
specified for text entries in which neither 
operand 2 nor operand 3 (see Figure 3) 
corresponds to the result operand (operand 
1) of the preceding text entry. The second 
is specified for text entries in which 
either operand 2 or operand 3 corresponds 
to the result operand. If operand 3 corre- 
sponds to the result operand, the two 
operands exchange roles, except for divi- 
Sion. In the case of division, operand 3 
is always in main storage. 


If both operands 2 and 3 correspond to 
the result operand of the previous text 
entry, an RR-format operation is specified 
to evaluate the interactions of the 
operands. 


In the actual process of basic register 
asSignment, a Single pass is made over the 
phase 15 text output. The basic unit 
operated upon is the text block. As the 
processing of each block is completed, the 
next is processed. When all blocks are 
processed, control is returned to the FSD. 


Text blocks are processed in a top-to- 
bottom manner, beginning with the first 
text entry in the block. When all text 
entries in a block are processed, the next 
text block is processed similarly. 


For any text entry, the machine code to 
be generated is first specified by setting 
up the status field of the text entry. 
Registers are then assigned to the operands 
and base addresses by filling in the 
register fields of the text entry. 


tatus Setting: Subroutine SSTAT-IEKRSS 
sets the operand and base address status 
information for a text entry in the follow- 
ing order: operand 2, operand 2 base 
address, operand 3, operand 3 base address, 
operand 1, and operand 1 base address. 


To set the status of operand 2, SSTAT- 
IEKRSS determines the relationship of that 
operand to the result operan: (operand 1) 
of the previous text entry. If operand 2 
is the same as the result operand, SSTAT- 
ITEKRSS sets the status of operand 2 to 
indicate that it is in a register and, 
therefore, need not be loaded; otherwise, 
it sets the status to indicate that it is 
in main storage. SSTAT-IEKRSS uses a simi- 
lar procedure to set the status of operand 
Su 


To set the status of the base address of 
operand 2, SSTAT-IEKRSS determines the 
relationship of that base address to the 
current base address (see note). If they 
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correspond, SSTAT-IEKRSS sets the status of 
the kase address of operand 2 to indicate 
that it is in a register and, therefore, 
need not be loaded; otherwise, it sets the 
status to indicate that it is in main 
storage. 


SSTAT-IEKRSS sets the statuses of the 
base addresses of operands 3 and 1 ina 
Similar manner. 


Note: The current base address is the last 
base address loaded for the purpose of 
referring to an operand. This base address 
remains current until a subsequent operand 
that has a different base address is 
encountered. When this occurs, the base 
address of the subsequent operand must be 
loaded. That base address then kecomes the 
current base address, etc. 


SSTAT-IEKRSS sets status of operand 1 to 
indicate whether or not the result of the 
interaction of operands 2 and 3 is to be 
stored into operand 1. If operand 1 is 
either an actual operand (a variable 
defined by the programmer) or a temporary 
that is not used in the subsequent text 
entry, it sets the status of operand 1 to 
indicate that the store is to be performed; 
otherwise, it sets the status to indicate 
that a store into operand 1 iS unnecessary. 


Register Assignment: After the status 
field of the text entry is completed, sub- 
routine SPLRA-IEKRSL assigns registers to 
the operands of the text entry and their 
associated base addresses in the same order 
in which statuses were set for them. 


The assignment of registers depends upon 
the statuses of the operands of the text 
entry. To asSign a register to operand 2, 
SPLRA-IEKRSL examines the status of that 
operand, and, if necessary, of orerand 3. 
If the status of operand 2 indicates that 
it iS in a register or if the statuses of 
operands 2 and 3 indicate that neither is a 
register, SPLRA-IEKRSL assigns operand 2 a 
register. It selects the register accord- 
ing to the type of operand (refer to Takle 
3), and places the number of that register 
into the R2 field of the text entry. 


To assign a register to the base address 
of operand 2, SPLRA-IEKRSL determines the 
Status of operand 2. If the status of that 
operand indicates that it is not ina 
register, it assigns a register to the base 
address of operand 2. The appropriate 
register is selected according to Table 3, 
and the register number is placed into the 
B2 field of the text entry. If the status 
of operand 2 indicates that it is ina 
register, SPLRA-IEKRSL does not assign a 
register to the base address of operand 2. 
SPLRA-IEKRSL uses a similar procedure in 
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asSigning a register to the base address of 
operand 3. 


If the status of operand 3 indicates 
that it is in a register, SPLRA-IEKRSL 
asSigns the appropriate register (refer to 
Table 3) to that operand, and enters the 
number of that register into the R3 field. 


Operand 1 is always assigned a register. 
SPLRA-IEKRSL selects the register according 
to the type of operand 1 (refer to Table 
3), and places the number of that register 
into the R1 field. 


The base address of operand 1 is 
asSigned a register only if the status of 
operand 1 indicates that it is to be stored 
into. If such is the case, SPLRA-IEKRSL 
selects the appropriate register, and 
records the number of that register in the 
B1 field. If the status of operand 1 indi- 
cates that it is not to be stored into, 
SPLRA-IEKRSL does not asSign a register to 
the base address of operand 1. 


When all the operands of the text entry 
and their associated base addresses are 
assigned registers, the next text entry is 
obtained, and the status setting and regis- 
ter assignment processes are repeated. 
After all text entries in the block are 
processed, control is returned to the con- 
trol routine of phase 20, which then makes 
the next block available tc the basic reg- 
ister assignment routines. When the pro- 
cessing of all blocks is completed, control 
is passed to the FSD. 


Full Register Assignment - OPT=1 


During full register assignment, also 
refer to “Full Register Assignment - 
OPT=2", as during basic register assign- 
ment, registers are assigned to the text 
entry operands and their associated base 
addresses, and the machine code to be 
generated for the text entries is speci- 
fied. To improve object module efficiency, 
these functions are performed in a manner 
that reduces the number of instructions 
required to load base addresses and 
operands. This process reduces the number 
of required load instructions by taking 
greater advantage of all available regis- 
ters, by assigning the registers as needed 
to both base addresses and operands, by 
keeping aS many Operands and basSe addresses 
as possible in registers and availabie for 
subsequent use, and by keeping the most 
active base addresses and operands in reg- 
isters where they are available for use 
throughout execution of the entire object 
module. 


During full register assignment, regis- 
ters are assigned at two levels: “locally" 


and "globally." Local assignment is per- 
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formed on a block-by-block basis. Global 
assignment is performed on the basis of the 
entire module (if intermediate- optimiza- 
tion has Leen specified). 


For local assignment, an attempt is made 
to keep operands whose values are defined 
within a block in registers and available 
for use throughout execution of that block. 
This is done by assigning an available reg- 
ister to an operand at the point at which 
its value is defined. (The value of an 
operand is defined when that operand 
appears in the operand 1 position of a text 
entry.) The same register is assigned to 
subsequent uses (i.e€., operand 2 or operand 
3 appearances) of that operand within the 
block, thereby ensuring that the value of 
the operand will be in the assigned regis- 
ter and available for use. However, if 
more than one subsequent use of the defined 
Operand occurs in the block, additional 
steps must Le taken to ensure that the 
value of that operand is not destroyed 
ketween uses. Thus, when the text entries 
in which the defined operand is used are 
processed, the code specified for them must 
not destroy the contents of the register 
containing the defined operand. 


Because all available registers are used 
during full register assignment, a number 
of operands whose values are defined within 
the block can be retained in registers at 
the same time. 


Applying the akove concept to an 
example, consider the following sequence of 


phase 15 text entries; 


A=xX +yY 
C=A+Z 
F=SA#C 


A register is assigned to A at the point at 
which its value is defined, namely in the 
text entry A= X + Y. The same register is 
assigned to the subsequent uses of A. The 
value of A will be accumulated in the 
assigned register and can be used in the 
subsequent text entry C = A + Z. However, 
kecause A is also used in the text entry 

F = A + C, the contents of the register 
containing A cannot ke destroyed by the 
code generated for the text entry C =A + 
Le Thus, when the text entry C =A +Zis 
processed, instructions are specified for 
that text entry that use the register con- 
taining A, but that do not destroy the con- 
tents of that register. 


In the example, C is also defined and 
subsequently used. To that defined operand 
and its subsequent uses, a register is 
assigned. The assigned register is dif- 
ferent from that assigned to A. The value 
of C will ke accumulated in the assigned 
register and can be used in the next text 


entry. The text entry F = A + C can then 
be evaluated without the need of any load 
operand instructions, because both the 
interacting operands (A and C) are in 
registers. 


This type of processing typifies that 
performed during local assignment for each 
block. When all blocks are processed, 
global assignment for the source module is 
carried out. 


Global assignment increases the effi- 
ciency of the object module as a whole by 
assigning registers to the most active 
operands and base addresses. The activi- 
ties of all operands and base addresses are 
computed during local assignment prior to 
global assignment. The first register 
available for global assignment is assigned 
to the most active operand or base address; 
the next available register is assigned to 
the next most active operand or base 
address; etc. As each such operand or base 
address is processed, a text entry, the 
function of which is to load the operand or 
base address into the assigned register, is 


generated and placed into the entry block(s) 


of the module. When the supply of 
operands and base addresses, or the supply 
of available registers, is exhausted, the 
process is terminated. 


All global assignments are recorded for 
use in a subsequent text scan, which incor- 
porates global assignments into the text 
entries, and completes the processing of 
operands that have neither been locally or 
globally assigned to registers (@.g., an 
infrequently used operand that is used ina 
block but not defined in that block). 


The full register assignment process is 
divided into five areas of operation: con- 
trol (subroutine REGAS-IEKRRG), table 
building (subroutine FWDPAS-IEKRFP), local 
assignment (subroutine BKPAS-IEKRBP) , glok- 
al asSignment (Subroutine GLOBAS-IEKRGB) , 
and text updating (subroutine STXTR- 
ITEKRSX). The control routine of phase 20 
(LPSEL-~IEKRSX) passes control to REGAS- 
IEKRRG which directs the flow of control 
among the other full register assignment 
routines. 


The actual assignment of registers is 
implemented through the use of tables Lkuilt 
by the table-building routine, with assis- 
tance from the control routine. Tables are 
built using the set of coordinate numbers 
and associated dictionary pointers created 
by phase 15 (MCOORD and MVD) for indexing. 
The table-building routine constructs two 
sets of parallel tables. One set, used by 
the local assignment routine, contains 
information about a text block; the second 
set, used by the global assignment rou- 
tines, contains information about the 
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entire module. (The local assignment and 
global assignment tables are outlined in 
Appendix A, “Register Assignment Tables.") 


The flow of control through the full 
register assignment routines is as follows: 


1. The control routine (REGAS-IEKRRG) 
makes a pass over the MVD table and 
the dictionary entries for the 
variables and constants in the loop 
passed to it, and constructs the 
eminence table (EMIN) for the module, 
which indicates the availability of 
the variables for global assignment. 
Then REGAS-IEKRRG calls the table 
building routine to process the blocks 
in the loop (the complete module for 
OPT=1). 


2. The table-building routine (FWDPAS- 
IEKRFP) builds the required set of 
local assignment tables and adds 
information to the global assignment 
tables under construction. FWDPAS- 
IEKRFP selects the first block of the 
loop and builds the takles for that 
block. It then passes control to the 
local assignment routine to process 
the block and the tables. 


3. The local assignment routine (BKPAS- 
TEKRBP) uses the tables supplied for 
the block to perform local register 
assignment, and returns control to 
FWDPAS-IEKRFP when its procesSing is 
completed. 


4. FWDPAS-IEKRFP selects the next block 
of the loop and again Ltuilds takles. 
This process continues until all 
blocks of the loop have been pro- 
cessed. Control is then returned to 
REGAS-IFKRRG. 


5. REGAS-IEKRRG passes control to the 
global assignment routine GLCBAS- 
IEKRGB, which performs global assign- 
ment for the module. 


6. When global assignment is complete, 
the control routine calls the text 
updating routine (STXTR-IEKRSX) to 
complete register assignment by enter- 
ing the results of glokal assignment 
into the text entries for the module. 
Control is then returned to 
(LPSFEL-IEKPLS) . 


Table Building for Register Assignment: 
The table-building routine, FWDPAS-IEKRFP, 


performs a forward scan of the intermediate 
text entries for the block under considera- 
tion and enters information about each text 
entry into the local and glokal tables 
(refer to Appendix A, “Register Assignment 
Takles"). The local assignment takles can 
accommodate information for 100 text 
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entries. PHAZ15 attempts to limit blocks 
to less than 100 text items. If, however, 
a block contains more than 100 text 
entries, the table-building routine builds 
the local tables for the first 100 text 
entries and passes this set of tables to 
the local assignment routine. The local 
assignment routine processes the text 
entries represented in the set of local 
tables. The table-building routine then 
creates the local tables for the next 100 
text entries in the block and passes them 
to the local assignment routine. When the 
table-building routine encounters the last 
text entry for the block, it passes control 
to the local assignment routine, although 
there may be fewer than 100 entries in the 
local tables. 


The global tables contain information 
relating to variables and constants 
referred to within the module, rather than 
to text entries. The global tables can 
accommodate information for 126 variables 
and constants in a given module. . Variables 
and constants in excess of this number 
within the module are not processed by the 
global assignment routine. 


Local Assignment: Local assignment is 
implemented via a backward pass over the 
text items for the block (or portion of a 
block) under consideration. The text items 
are referred to by using the local assign- 
ment tables, which supply pointers to the 
text items. 


The local assignment routine, BKPAS- 
IEKRBP, examines each operand in the text 
for a block and determines (from the local 
assignment tables) if the operand is elig- 
ible for local assignment. To be eligible, 
an operand must be defined and used (in 
that order) within a block. Because local 
assignment is performed via a backward pass 
over the text, an eligible operand will be 
encountered when it is used (i.e., in the 
operand 2 or 3 position) before it is 
defined. 


When an operand of a text entry is 
examined, the local assignment routine 
(BKPAS-IEKRBP) consults the local assign- 
ment tables to determine that operand's 
eligibility. If the operand is eligible, 
BKPAS-IEKRBP assigns a register to it. The 
register assigned is determined by consult- 
ing the register usage table (TRUSE). 

TRUSE is a work table that contains an 
entry for every register that may be used 
by the local assignment routine. A zero 
entry for a particular register indicates 
that the register is available for local 
assignment. A nonzero entry indicates that 
the register is unavailable and identifies 
the variable to which the register is 
asSigned. The register usage table is 
modified each time a register is assigned 
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or freed. The first time a register is 
asSigned, a corresponding entry in the 
register usage table for glokal assignment 
(RUSE) is set. This entry implies that the 
register is unavailakle for global 
assignment. 


BKPAS-IEKRBP records the register 
assigned to the used operand in the local 
asSignment tables and in the text item con- 
taining the used operand. It sets the sta- 
tus of the operand in the text entry to 
indicate that it is in a register. If sub- 
sequent uses of the operand are encountered 
prior to the definition of the operand, 
BKPAS-IEKRBP uses the register assigned to 
the first use, and records its identity in 
the text item. It then sets the status 
bits for the operand to indicate that it is 
in a register and is to be retained in that 
register. | 


When a definition of the operand is 
encountered, BKPAS-IEKRBP enters the 
register assigned to the operand into the 
text item and sets the status for the 
operand to indicate its residence ina 
register. Once the register is assigned to 
the operand at its definition point, BKPAS- 
IEKRBP frees the register by setting the 
entry in the register usage table to zero, 
making the register available for assign- 
ment to another operand. 


If the block being processed contains a 
CALL statement, common variables and real 
operands cannot be assigned to registers 
across that reference. In addition, if the 
block contains a reference to a function 
Subprogram, no local assignment may be made 
for real operands across the reference to 
that function. The local asSignment rou- 
tine assumes that: 


1. All mathematical functions return the 
result in general register 0 or 
floating-point register 0, according 
to the mode of the function. 


2. The imaginary portion of a complex 
result is returned in floating-point 
register 2. 


If no register is available for assign- 
ment to an eligible operand, an overflow 
condition exists. In this case, BKPAS- 
ITEKRBP must free a previously assigned 
register for assignment to the current 
operand. It scans the local assignment 
tables and selects a register. It then 
modifies the local assignment tables, text 
entries for the block, and register usage 
table to negate the previous assignment of 
the selected register. The required 
register is now available, and processing 
continues in the normal fashion. 


Global Assignment: The global assignment 
routine (GLOBAS-IEKRGB) , unlike the local 
asSignment routine, does not process any of 
the text entries for the module. The glob- 
al assignment routine operates only through 
the set of global tables. The results of 
global assignments are entered into the 
appropriate text entries by the text updat- 
ing routine. 


Before assigning registers, the global 
assignment routine modifies the global 
assignment tables to produce a Single acti- 
vity table for all operands and base 
addresses in the module. 


Global assignment is then performed 
based on the activity of the eligible 
operands and base addresses. 


GLOBAS-IEKRGB determines the eligibility 
of an operand or base address by consulting 
the appropriate entry in the global assign- 
ment tables. Eligible operands are divided 
into two categories: floating point and 
fixed point. The two categories are pro- 
cessed separately, with floating-point 
quantities processed first. 


A register usage table (RUSE) of the 
same type as described under local assign- 


ments (TRUSE) is used by the global assign- 
ment routine. For each category of 
operands, GLOBAS-IEKRGB selects the elig- 
ible operand with the highest total activi- 
ty and assigns it the first available 
register of the same mode. It records the 
asSignment in the register usage table and 
in the global assignment tables. GLOBAS- 
IEKRGB then selects the eligible operand 
with the next highest activity and treats 
it in the same manner. Processing for each 
group continues until the supply of elig- 
ible operands or the supply of available 
registers is exhausted. 


If the module contains any CALL state- 
ments, real and common variables are 
ineligible for global assignment. If the 
module contains any references to function 
subprograms no global assignment can be 
performed for real quantities. In other 
words, if a module contains both a 
reference to a subroutine and to a function 
Subprogram, global assignment is restricted 
to integer and logical operands that are 
not in common. 


Text Updating: The text updating routine 
(STXTR-IEKRSX) completes full register 
assignment. It scans each text entry 
within the series of blocks comprising the 
module, looking at operands 2, 3, and 1, in 
that order, within each text entry. As 
each operand is processed, STXTR-IEKRSX 
interrogates the completed global assign- 
ment table to determine if a global assign- 
ment has been made for the operand. If it 
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has, STXTR-IEKRSX enters the register 
assigned into the text entry and sets the 
operand status bits to indicate that the 
operand is in a register and is to be 
retained in that register. 


If both a local and a glokal assignment 
have been made for an operand, the global 
assignment supersedes the local assignment 
and STXTR-IEKRSX records the glokally 
assigned register in the text items per- 
taining to that operand. It also sets the 
status bits for such an operand to indicate 
that it is in a register and is to be 
retained in that register. 


If a register has not been assigned 
either locally or globally for an operand, 
STXTR-IEKRSX determines and records in the 
text entry the required base register for 
the base address of that operand. If the 
kase address corresponds to one that has 
been assigned a register during global 
asSignment, STXTR-IEKRSX assigns the same 
register as the base register for the 
operand. If a register has not been 
assigned to the base address of the operand 
during global assignment, it assigns a 
Spill register (register 15) as the hase 
register of the operand. STXTR-IEKRSX sets 
the operand's Lase status bits to indicate 
whether or not the base address is ina 
register. (The base address will be ina 
register if one was assigned to it during 
global assignment.) It then assigns the 
operand itself a spill register (general 
register 0 or 1 or floating-point register 
0, depending upon its mode). 


As part of its text updating function, 
STXTR-IEKRSX allocates temporary storage 
where needed for temporaries that have not 
been assigned to a register, keeps track of 
the allocated temporary storage, and com- 
pletes the register fields of text entries 
to ensure compatibility with phase 25. On 
exit from the text updating routine, all 
text items in the module are fully formed 
and ready for processing by phase 25. The 
text updating routine returns control to 
REGAS-IEKRRG upon completion of its func- 
tions. REGAS-IEKRRG, in turn, returns con- 
trol to (LPSEL-IEKPLS) . 


BRANCHING OPTIMIZATION - OPT=1 


This portion of phase 20 optimizes 
bkranching within the object module. The 
optimization is achieved by generating RX- 
format branch instructions in place of RR- 
format branch instructions wherever 
possible. 


The use of RX-format branches eliminates 
the need for an instruction to load the 
branch address into a general register pre- 
ceding each branching instruction. Thus, 
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branching optimization decreases the size 
of the object module by one instruction for 
each RR-format branch instruction in the 
object module that can be replaced by an 
RX-format branch instruction. It also 
decreases the number of address constants 
required for branching. 


Phase 20 optimizes branching instruc- 
tions by calculating the size of each text 
block (number of bytes of object code to ke 
generated for that block) and by determin- 
ing those blocks that can be branched to 
via RX-format branch instructions. 


Subroutine BLS-IEKSBS calculates the 
Sizes of all text blocks after full regis- 
ter assignment for the module is completed. 
It then uses the gathered block size infor- 
mation to determine the blocks that can be 
branched to by means of RX-format branch 
instructions. BLS-IEKSBS calculates the 
number of bytes of object code by: 


1. Examining each text item operation 
code and the status of the operands 
(i.e., in registers or not). 


2. Determining, from a reference table, 
the number of bytes of code that is to 
be generated for that text item. 


BLS-IEKSBS accumulates these values for 
each block in the module. In addition, it 
increments the block size count by the 
appropriate number of bytes for each 
encountered reference to an in-line 
routine. 


Next BLS-IEKSBS computes all block sizes 
and determines those text blocks that can 
be branched to via RX-format branch | 
instructions. A text block, once converted 
to machine code, can be branched to via an 
RX-format branch instruction if the rela- 
tive address of the beginning of that block 
is displaced less than 4096 bytes from an 
address that is loaded into a reserved 
register. 


The following text discusses reserved 
registers, the addresses loaded into then, 
and the processing performed by BLS-IEKSBS 
to determine the source module blocks that 
can be branched to via RX-format branch 
instructions. 


Reserved Registers 


Reserved registers are allocated to con- 
tain the Starting address of the adcon 
table and subsequent 4096-byte blocks of 
the object module. The criterion used by 
phase 20 in reserving registers for this 
purpose is the number of text entries that 
result from phase 15 processing. (Phase 15 
counts the number of text entries that 
result from its processing and passes the 
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information to phase 20.) For relatively 
small source modules (approximately 70 
source statements) , phase 20 reserves only 
one register. For sufficiently large 
source modules (approximately 280 source 
statements) , a maximum of five is reserved. 
The registers are reserved, as needed, in 
the following order: register 13, 12, 11, 
10, and 9. 


Reserved Register Addresses 


The addresses placed into the reserved 
registers as a result of the execution of 
the initialization instructions (refer to 
Fortran System Director, “Generation of 
Initialization Instructions") are: 


e Register 13 - address of the save area. 


e Register 12 (if reserved) - address of 
the save area plus 4096 or address of 
the first adcon for the program. 

e Register 11 (if reserved) - address of 

the register 12 plus 4096. 


e Register 10 (if reserved) - address of 
the register 12 plus 2 (4096). 


e Register 9 (if reserved) - address of 
the register 12 plus 3 (4096). 


Block Determination and Subsequent ‘ 
ProcesSing 


Because the instructions resulting from 
the compilation are entered into text 
information immediately after the adcon 
taklie (see Figure 11), certain text ;Llocks 
are displaced less than 4096 bytes from an 
address in a reserved register. Such 
blocks can be branched to by RX-format 
branch instructions that use the address in 
a reserved register as the kase -address for 
the branch. 


To determine the blocks that can be 
branched to via RX-format branch instruc- 
tions, BLS-IEKSBS computes the displacement 
(using the Elock size information) of each 
block from the address in the appropriate 
reserved register. The first reserved reg- 
ister address considered is that in regis- 
ter 13. If a block displaced less than 
4096 Lytes from that address exists, BLS- 
IEKSBS enters the displacement of that 
klock (from the address) into the statement 
number entry. It also places in that 
statement number entry an indication that 
the block can be transferred to via an RX- 
format branch instruction, and records the 
number of the reserved register to be used 
in that branch instruction. 


ME 


When BLS-IEKSBS has processed all klocks 
disclaced less than 4096 bytes from the 
address in register 13, it processes those 


displaced less than 4096 bytes from the 
addresses in registers 12, 11, 10, and 9 
(if reserved) in a similar manner. 


The information placed in the statement 
number entries is used during code genera- 
tion, a phase 25 process, to generate RX- 
format branch instructions. 


STRUCTURAL DETERMINATION 


To achieve CPT=2 optimization, the 
Structural determination routines of phase 
20 (TOPO-ILEKPO and BAKT-IEKPB) identify 
module loops and specify the order in which 
they are to be processed. Loops are iden- 
tified by analyzing the block connection 
information gathered by phase 15 and reco- 
rded in the forward connection (RMAJOR) and 
backward connection (CMAJOR) tables. The 
connection information indicates the flow 
of control within the module and, there- 
fore, reflects which blocks pass control 
among themselves in a cyclical fashion. 


Loops are ordered for procesSing start- 
ing with the innermost, or most often 
executed, loop and working outward. The 
inner-to-outer loop sequence is specifed so 
that: 


e Text entries will not be relocated into 
loops that have already been 
processed.1 


e The full register capabilities of 
System/360 can first be applied to the 
most frequently executed (innermost) 
loop. 


Loop identification iS a sequential pro- 
cess, which first requires that a back 
dominator be determined for each text 
block. The back dominator of a text block 
(block 1) is defined as the block nearest 
to block I through which control must pass 
before block I receives control for the 
first time. The back dominators of all 
text blocks must be determined before loop 
identification can be continued. After all 
back dominators have been determined, a 
chain of back dominators is effectively 
established for each block. This chain 
consists of the back dominator of the 
block, the back dominator of the back 
dominator of the block, etc. 


UE NE ee oe ee ee 


1The text optimization process relocates 
text entries from within a loop to an outer 
loop. Thus, if an outer loop were pro- 
cessed first, text entries from an inner 
loop might be relocated to the outer loop, 
thereby requiring that the outer loop be 
reprocessed. 
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Figure 7 illustrates the concept of back 
dominators. Each block in the figure 
represents a text block. The blocks are 
identified by single letter names. The 
kack dominator of each block is identified 
and recorded above the upper right-hand 
corner of that block. 


Entry 





Exit 


Figure 7. Back Dominators 


When all back dominators are identified, 
a back target and a decgth number for each 
text block are determined. A block (block 
I) has a kack target (block J) if: 


e There exists a path from tlock I to 
itself that does not pass through block 
ie 


e Block J is the nearest ktlock in the 
chain of back dominators of block I 
that has only one forward connection. 


The text blocks constituting a loop are 
identifiakle because they have a common 
back target, known as the back target of 
the loop. 


The depth number for a block indicates 
the degree to which that block is nested 
within loops. For example, if a block is 
an element of a loop that is contained 
within a loor with a depth number of one, 
that block has a depth number of two. All 
blocks constituting the same loop (i.e., 
all blocks having a common target) have the 
same depth number. 
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The depth numbers computed for the 
blocks that comprise the various loops are 
used to determine the order in which the 
loops are to be processed. 


Figure 8 illustrates the concepts of 
back targets and depth numbers. Again each 
block in the figure represents a text 
block, which is identified by a single 
letter name. In this figure, the back tar- 
get of each block is identified and record- 
ed above the upper right-hand corner of 
that block. The depth number for the block 
is recorded above the upper left-hand cor- 
ner of the block. Note that blocks that 
pass control among themselves in a looping 
fashion have a common back target and the 
Same depth number. Also note that the 
blocks of the two inner loops have the same 
depth numbers, although they have different 
back targets. 





Exit 


Figure 8. Back Targets and Depth Numbers 
When the back target and depth number of 
each text block has been determined, loops 
are identified and the order in which they 
are to be processed is specified. The 
loops are ordered according to the depth 
number of their blocks. The locp whose 
blocks have the highest depth number is 
Specified as the first to be processed; the 
loop whose blocks have the next highest 
depth number is specified as the second to 
be processed; etc. When the processing 
order of all loops has been established, 
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the innermost loop is selected for 
processing. 


The following paragraphs describe the 
processing performed by the structural 
determination routines to: 


e Determine the back dominator of each 
text klock. 

e Determine the back target and depth 
number of each text block. 

e Identify and order loops for 
processing. 


Determination of Back Dominators 


Subroutine TOPO-IEKPO determines the 
back dominator of each text block by 
examining the connection information for 
that klock. The first klock processed by 
TOPO-IEKPO is the first block (entry block) 
of the module. Blocks on the first level 
(1.-e., blocks that receive control from the 
entry block) are processed next. Second- 
level blocks (i.e., blocks that receive 
control from first-level blocks) are then 
processed, etc. 


TOPO-IEKPO assigns the entry block a 
back dominator of zero, because it has no 
back dominator; it records the zero in the 
kack dominator field of the statement num- 
ker entry for that block (refer to Appendix 
A, “Statement Number/Array Table"). TOPO- 
IEKPO asSigns each block on the first level 
either its actual back dominator or a pro- 
visional kack dominator. If a first-level 
block receives control from only one block, 
that block must be the entry Llock and is 
the back dominator for the first-level 
block. TOPO-IEKPO records a pointer to the 
statement number entry for the entry block 
in the back dominator field of the state- 
ment number entry for the first level- 
block. If a first-level block receives 
control from more than one block, TOPO- 
IEKPO assigns it a provisional back domina- 
tor, which is the entry block of the 
module. All blocks on the first level are 
processed in this manner. 


TOPO-IEKPO also assigns each block on 
the second level either its actual back 
dominator or a provisional back dominator. 
If a second-level block receives control 
from only one block, its back dominator is 
the first-level block from which it 
receives control. TOPO-IEKPO records a 
pointer to the statement number entry for 
the first-level block in the back dominator 
field of the statement number entry for the 
second-level block. If more than one block 
passes control to a second-level block, 
TOPO-IEKPO assigns that block a provisional 
kack dominator. The provisional Lack 
dominator assigned is a first-level block 
that passes control to the second-level 
block under consideration. Processing of 


this type is performed at each level until 
the last, or exit, block of the module is 
processed. TOPO-IEKPO then determines the 
actual back dominators of blocks that were 
asSigned provisional back dominators. 


For each block assigned a provisional 
back dominator, subroutine TOPO-IEKPO makes 
a backward trace over each path leading to 
the block (uSing CMAJOR). The blocks at 
which two or more of the paths converge are 
flagged as possible candidates for the back 
dominator of the block. When all paths 
have been treated, the relationship of each 
possible candidate to the other possible 
candidates is examined. TOPO-IEKPO assigns 
the candidate at the highest level (i.e., 
closest to the entry block of the module) 
as the back dominator of the block under 
consideration; it records a pointer to the 
statement number entry for the assigned 
back dominator in the back dominator field 
of the statement number entry for the Llock 
under consideration. After the back 
dominators of all text blocks are identi- 
fied, Subroutine BAKT-IEKPB determines the 
back target and depth number of each text 
block. 


Determination of Back Targets and Depth 
Numbers 


Subroutine BAKT-IEKPB determines the 
back target of each text block through an 
analysis of the backward connection infor- 
mation (in CMAJOR) for that block. Block J 
is the back target of biock I if: 


Ts Block J is the nearest block in the 
chain of back dominators of block I. 


2. Block J has only one forward 
connection. 


3. There exists a path from block I to 
itself that does not pass through 
block J. 


Tf a block J exists that satisfies all 
the above conditions except the second, 
then the back target of block J is also the 
back target of block I. 


If a block J satisfying conditions 1 and 
3 does not exist, then the back target of 
block I is zero. 


When the back target of a block is iden- 
tified, that block is also assigned a depth 
number. 


Back targets and depth numbers are 
determined for text blocks in the same 
order as back dominators are determined for 
them. The first block of the module is the 
first processed; first-level blocks are 
considered next; etc. 
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RAKT-IEKPB assigns the first or entry 
block both a back target and depth number 
of zero, because it does not have a back 
target and is not ina loop. It records 
the depth number (zero) in the loop number 
field of the statement iumber entry for the 
entry block (refer to Appendix A, “State- 
ment Number/Array Table"). 


The processing performed by BAKT-IEKPB 
for each other block depends upon whether 
one or more than one block passes control 
to that block. If more than one block 
passes control to the block under consi- 
deration, BAKT-IEKPB makes a backward trace 
over ail paths leading to that block to 
locate its primary path. The primary path 
of a block (if one exists) is a path that 
Starts at that block and converges on that 
block without passing through any block in 
the chain of back dominators of that block. 


If such a path exists, BAKT-IEKPB 
obtains and examines the nearest block in 
the chain of back dominators of the block 
under consideration. If the obtained block 
has a single forward connection, BAKT-IEKPB 
assigns that block as the kack target of 
the block under consideration.  BAKT-IEKPB 
then assigns a depth number to the block. 
The number is one greater than that of its 
back target, because the block iS ina 
loop, which must be nested within the loop 
containing the back target. BAKT-IEKPB 
records the depth number in the loop number 
field of the statement number entry for the 
block. 


If the obtained block has more than one 
forward connection, BAKT~IEKPB assigns its 
kack target as the back target of the block 
under consideration. BAKT-IEKPB then 
records in the statement number entry for 
the -Llock a depth number one greater than 
that of its back target. 


If a block that receives control from 
two or more blocks does not have an asso- 
Ciated primary path, that block, if it is 
in a loop at all, is in the same loop as 
one of the blocks in its chain of back 
dominators. To identify the loop contain- 
ing the Elock (block I), BAKT-IEKPB obtains 
and examines the nearest block to block I 
in its chain of back dominators that has 
two or more forward connections. BAKT- 
IEKPB makes a backward trace over all paths 
leading to the obtained block to determine 
whether or not block I is an element of 
such a path. If block I is an element of 
such a path, it iS in the same loop as the 
oktained block, and BAKT~-IEKPB therefore 
asSigns block I the same back target and 
depth number as the obtained block; it 
records the depth number in the statement 
number entry for block I. 
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If block I is not an element of any path 
leading to the obtained block, BAKT-IEKPB 
obtains the next nearest block to block I 
in its chain of back dominators that has 
two or more forward connections and repeats 
the process. If block I is not an element 
of any path leading to any block in its 
chain of back dominators, block I is not in 
a loop, and BAKT-IEKPB asSigns it both a 
back target and depth number of zero. 


A block that receives control from only 
one block, if it iS ina loop at all, is in 
the same loop as one of the blocks in its 
chain of back dominators. To identify the 
loop containing a block (block I) that 
receives control from only one block, BAKT- 
IEKPB obtains and examines the nearest 
block to block I in its chain of Lack 
dominators that receives control from two 
or more blocks. BAKT-IEKPB makes a Lack- 
ward trace over all paths leading to the 
obtained block to locate itS primary path 
(if any). If the obtained block has a pri- 
mary path, BAKT-IEKPB retraces it to deter- 
mine if block I is an element of the path. 
If it is, block I is in the same loop as 
the obtained block, and, BAKT-IEKPB there- 
fore assigns block I the same back target 
and depth number as the obtained block; it 
records the depth number in the statement 
number entry for block I. 


If the obtained block does not have a 
primary path, or if it does have a primary 
path, which, however, does not have Llock I 
as an element, BAKT-IEKPB considers the 
next nearest block to block I in its chain 
of back dominators that receives control 
from two or more blocks. The process is 
repeated until a primary path containing 
block I is located (if any such path 
exists). If block I is not in the primary 
path of any block in its chain of back 
dominators, block I is not in a loop and 
BAKT-IEKPB assigns it both a back target 
and depth number of zero. 


Identifying and Ordering Loops for 
Processing 


Subroutine BAKT-IEKPB orders blocks for 
processing on the basis of the determined 
back target and depth number information. 
Blocks that have a common back target and 
the same depth number constitute a loop. 
BAKT-IEKPB flags the loop with the highest 
depth number (therefore, the most deeply 
nested loop) as the first loop to be pro- 
cessed. It assigns the blocks constituting 
that loop a loop number of one, indicating 
that they form the innermost loop, which is 
the first to undergo optimization. (BAKT-— 
IEKPB records the value 1 in the loop nunm- 
ber field of the statement number entry for 
each block in that loop.) BAKT-IEKPB flags 
the loop with the next highest depth number 
as the second loop to be processed. It 
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assigns the blocks in that loop a loop nun- 
ker of two, indicating that they form the 
second (or next outermost) loop to be pro- 
cessed. (A value of 2 is recorded in the 
loop number field of the statement numker 
entry for each block in that loop.) BAKT- 
IEKPB repeats this procedure until the lcor 
with a depth number of one is processed. 

It then assigns the highest loop number to 
the blocks with a depth number of zero, 
indicating that they do not form a loop. 


If at any time, groups of blocks with 
the same depth number but different Lack 
targets are found, each group is ina dif- 
ferent loop. Therefore, each such loop is, 
in turn, processed before blocks having a 
lesser depth number are considered. Thus, 
if the blocks of two loops have the same 
depth number, BAKT-IEKPB assigns the blocks 
of the first loop the next loop number. It 
asSigns the blocks of the second loop a 
loop numker one greater than that assigned 
to the blocks of the first loop. 


When loop numbers are assigned to the 
blocks of all module loops, the order in 
which the loops are to ke processed has 
been specified. Control is passed to the 
routine that determines the busy-on-exit 
information and then to the loop selection 
routine to select the first (innermost) 
loop to be operated upon. This loop con- 
Sists of all blocks having a loorg number of 
one. 


BUSY-ON-EXIT INFORMATICN 


Before the module can be processed ona 
loop-by-loop basis, information indicating 
which variakles are Eusy-on-exit from which 
text blocks must be gathered. A variakle 
is busy immediately preceding a use of that 
variable, but is not busy immediately pre- 
ceding a definition of that variable. 

Thus, a variable is busy-on-exit from the 
blocks which are along all paths connecting 
a use and a prior definition of that vari- 
able. This means that in suksequent Elocks 
the variable can be used before it is 
defined. The busy-on-exit condition for a 
variakle assures that its proper value 
exists in main storage or in a register 
along each path in which it is suksequently 
used. 


Information about the regions in which a 
variakle is busy or not busy determines 
whether or not a definition of that vari- 
akle can ke moved out of a loop. For 
example, if a variable is busy-cn-exit from 
the kack target of a loop, text optimiza- 
tion (see “Text Optimization") would not 
attempt to move to the Lack target a redef- 
inition of that variable, because, if 
moved, the value of the variable, as it is 
processed along various paths from the Lack 


target, might not be the desired one. Con- 
versely, if the variable is not busy-on- 
exit, the redefinition can be moved without 
affecting the desired value of the vari- 
able. Thus, text optimization respects the 
redefinitions of variables that are busy- 
on-exit from the back target of a loop. 


The information about regions in which a 
variable is busy or not busy also deter- 
mines whether or not loads and stores of a 
register assigned to the variable are 
required. For example, in full register 
assignment (see “Full Register Assignment- 
OPT=2"), variables that are asSigned regis- 
ters during global assignment and that are 
busy-on-exit from the back target of the 
loop must have an initializing load of the 
register placed into the back target. The 
load is required because the variable may 
be used before its value is defined. Con- 
versely, if the globally assigned variable 
is not busy-on-exit from the back target, 
an initializing load is unnecessary. 


Pnase 15 provides phase 20 with not 
busy-on-entry information for each operand 
that is assigned a coordinate (an MVD table 
entry). The not busy-on-entry information 
is recorded in the MVX field of the state- 
ment number text entry for each text block 
(see phase 15, “Gathering Constant/Variable 
Usage Information"). An operand is not 
busy-on-entry to a block, if in that block 
that operand is only defined or defined 
before it is used. Phase 20 converts the 
not busy-on-entry information to busy-on- 
entry information. An operand is busy-on- 
entry to a block, if in that block that 
operand is only used or used before it is 
defined. Finally, phase 20 converts the 
busy-on-entry information to busy-on-exit 
information. The backward connection 
information in CMAJOR is used to make the 
final conversion. 


The routine that performs the conver- 
Sions iS BIZX-IEKPZ. This routine deter- 
mines busy-on-exit information for each 
constant, variable, and base variable hav- 
ing an associated MVD table entry or coor- 
dinate. However, because constants and 
base variables are only used, they are 
busy-on-exit throughout the entire module. 
Therefore, the remainder of this discussion 
deals with the determination of busy-on- 
exit information for variables. 


Because RETURN statements (exit blocks) 
and references to subprograms not supplied 
by IBM constitute implicit uses of 
variables in common, all common variables 
and arguments to such subprograms are first 
marked as busy-on-entry to exit blocks and 
blocks containing the references. The com- 
mon variables and arguments are found by 
examining the information table entries for 
all variables in the MVD table. The module 
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is then searched for blocks that are exit 
blocks and that contain references to sub- 
programs not supplied by IBM. The coordin- 
ate bit for each previously mentioned vari- 
able is set on in the MVF field of the 
statement number text entry for each such 
block, while the same coordinate bit in the 
MVX field is set off. This defines the 
variable to be busy-on-entry to such a 
block. During this process, a table, con- 
Sisting of pointers to exit blocks, is 
built for subsequent use. 


After the blocks discussed above have 
been appropriately marked for common 
variakles and arguments, BIZX-IEKPZ, work- 
ing with the coordinate assigned to a vari- 
able, converts the not busy-on-entry infor- 
ration for the variable to a table of 
pointers to blocks to which the variable is 
busy-on-entry. (The not busy-on-entry 
information for the variable is contained 
in the MVX fields of the statement number 
text entries for the various text blocks.) 
At the same time, the variable's coordinate 
bit in each MVX field is set off. The 
busy-on-exit table and CMAJOR are then used 
to set on the MVX coordinate bit in the 
statement number text entry for each block 
from which the variakle is busy-on-exit. 
This procedure is repeated until all 
variakles have been processed. Control is 
then returned to LPSEL-IEKPLS. 


To convert not busy-on-entry information 
to busy-on-entry information, BIZX-IEKPZ 
Starts with the second MVD table entry, 
which contains a pointer to the variable 
asSigned coordinate number two, and works 
down the chain of text blocks. The asso- 
Ciated MVX coordinate bit in the statement 
number text entry for each LElock is 
examined. If the coordinate bit is off, 
the corresponding MVF ccordinate bit is 
inspected. If the MVF coordinate bit is 
on, a pointer to the associated text block 
is placed into the busy-on-entry table. 
This defines the variable to be busy-on- 
entry to the block (i.e., the variable is 
used in the block before it is defined). 
If the associated MVX coordinate bit is on, 
indicating that the variable is not busy- 
on-entry, BIZX-IEKPZ sets the bit off and 
proceeds to the next block. This process 
is repeated until the last text block has 
keen processed. 


After BIZX-IEKPZ has set off the MVX 
coordinate bit (associated with the vari- 
able under consideration) in each statement 
number text entry and built a takle of 
pointers to blocks to which the variable is 
busy-on-entry, it determines the blocks 
from which the variable is busy-on-exit. 


Starting with the first entry in the 


kusy-on-entry table, BIZX-IEKPZ obtains 
(from CMAJOR) fointers to all blocks that 
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are backward connections of that entry. 
Each backward connecting block is examined 
to determine whether or not it meets one of 
three criteria, which are: 


e The block contains a definition of the 
variable (i.e., the variable's MVS 
coordinate bit is on). | 


e The variable has already been marked as 
busy-on-exit from the block. 


e The block corresponds to the busy-on- 
entry table entry being processed. 


If the block meets one of theSe cri- 
teria, the variable is busy-on-exit from 
the block and its associated MVX coordinate 
bit is set on. (The backward connections 
of that block are not explored.) 


If the backward connecting block does 
not meet any one of these criteria, the 
variable is marked as busy-on-exit from 
that block and that block's backward con- 
nections are, in turn, explored. The same 
criteria are then applied to the backward 
connecting blocks. The backward connection 
paths are explored in this manner until a 
block in every path satisfies one of the 
criteria. 


If, during the examination of the back- 
ward connections, an entry block (i.e., a 
block lacking backward connections) is 
encountered, the blocks in the table of 
exit blocks, which was previously built by 
BIZX-IEKPZ are used as the backward connec- 
tions for the entry block. Processing then 
continues in the normal fashion. 


When blocks in all backward connecting 
paths have satisfied one of the criteria, 
BIZX-IEKPZ obtains the next entry in the 
busy-on-entry table and repeats the pro- 
cess. This continues until the busy-on- 
entry table has been exhausted. 


When the busy-on-entry table has been 
exhausted, the procedure of building the 
busy-on-entry table and converting it to 
busy-on-exit information is repeated for 
the next MVD table entry. When all MVD 
table entries have been processed, BIZxX- 
IEKPZ passes control to LPSEL-IEKPLS, which 
calls the loop selection routines. 


STRUCTURED SOURCE PROGRAM LISTING 


If both the EDIT option and OPT=2 opti- 
mization are selected, after subroutine 
BIZX-IEKPZ has compiled the busy-on-exit 
information, control is passed to subrou- 
tine SRPRIZ-IEKQAA, which records on the 
SYSPRINT data set a structured source pro- 
gram listing. This listing indicates the 
loop structure and logical continuity of 
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the source program. (A complete descrip- 
tion of the structured source listing is 
given in the publication IBM System/360 
Operating System: FORTRAN IV (H) Program- 


mer's Guide.) 


To produce the listing, SRPRIZ-IEKQAA 
reads the SYSUT1 data set prepared by phase 
10 and associates, by means of statement 
numbers, the individual source statements 
with the text blocks formed from them. By 
analysis of the loop number information 
gathered for the text blocks, SRPRIZ-IEKQAA 
then identifies the source statements that 
make up a particular loop and flags them on 
the listing Ly corresponding loor number. 
SPRRIZ-IEKQAA also uses the previously 
gathered kack dominator information to com- 
pute listing indentations for the state- 
ments. The indentations show dominance 
relationships; that is, SRPSIZ-IEKQAA 
indents the statements that form a text 
klock from the statements that form the 


back dominator of that block. 


LCOP SELECTION 


The loop selection routine of phase 20 
(TARGET-IEKPT) selects the loop to be pro- 
cessed and provides the text optimization 
and full register assignment routines with 
the information required to process the 
loor. 


The loop to be processed is selected 
according to the value of a loop number 
parameter, which is passed to the loop 
selection routine. The control routine of 
phase 20 (LPSEL-IEKPLS) sets this parameter 
to one after the process of structural 
determination is complete. The loop selec- 
tion routine TARGET-IEKPT is called to 
select the loop whose blocks have a corre- 
sponding loop number. The selected loop is 
then passed to the text optimization rou- 
tines. When text optimization for the loor 
is completed, the control routine incre- 
ments the parameter by one, sets the loor 
number of the blocks in the loop just pro- 
cessed to that of their back target, and 
marks those blocks as completed. The con- 
trol routine again calls TARGET-IEKPT, 
which selects the loop whose blocks corre- 
spond to the new value of the parameter. 
The selected loop is then passed to the 
text optimization routines. This process 
is repeated until the outermost loop has 
been text-optimized. 


After text optimization has processed 
the entire module (i.e., the last loop), 
the control routine removes the klock com- 
pletion marks, initializes the loop number 
parameter to 1, and passes control to 
TARGET-IEKPT to reselect the first loop. 
Control is then passed to the full register 
asSignment routines. When full register 
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register assignment. 


assignment for the loop is completed, the 
control routine marks the blocks of the 
loop as completed. It then increments the 
parameter by 1 and passes control to 
TARGET-IEKPT to select the next loop. Full 
register assignment is then carried out on 
the loop. This process is repeated until 
the outermost loop has undergone full 

(When full register 
assignment has been carried out on the out- 
ermost loop, the control routine passes 
control to the routines that compute the 
Size of each text block and then to the 
routine that computes the displacements 
required for branching optimization.) 


The loop selection routine TARGET-IEKPT 
uses the value of the loop number parameter 
as a basis for selecting the loop to be 
processed. TARGET-IEKPT compares the loop 
number assigned to each text block to the 
parameter. It marks each block having a 
loop number corresponding to the value of 
the parameter as an element of the loop to 
be processed. It does this by setting ona 
bit in the block status field of the state- 
ment number entry for the block (refer to 
Appendix A, “Statement Number/Array 
Table"). When all such blocks are marked, 
the loop has been selected. 


The information required by the text 
optimization and full register assignment 
routines to process the loop consists of 
the following: 


e A pointer to the back target of the 
loop (if any). 


e A pointer to the forward target of the 
loop (if any). 


e Pointers to both the first and last 
blocks of the loop. 


e The loop composite matrixes. 


After the loop has been selected, this 
required information is gathered. 


Pointer to Back Target 


The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the back 
target of the loop. Although the back tar- 
get of the loop was previously identified 
during structural determination, it was not 
saved. Therefore, its identity must be 
determined again. 


The loop selection routine TARGET-IEKPT 
determines the back target of the loop by 
obtaining the first block of the selected 
loop. It then analyzes the blocks in the 
chain of back dominators of the first -Llock 
to locate the nearest block in the chain 
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that is outside the loop and that passed 
control to only one block. That block is 
the back target of the loop, and TARGET- 
IEKPT saves a pointer to it for use in the 
subsequent processing of the loop. 


Pointer to Forward Target 


The text optimization and full register 
assignment routines place both relocated 
and generated text entries into the forward 
target of the loop. The forward target of 
a loop (if it exists) is the single block 
to which the loop passes control after its 
execution is complete. 


To locate the forward target (if any), 
the loop selection routine TARGET-IEKPT 
analyzes the backward connection informa- 
tion (in CMAJOR) for each block that is not 
in the selected loop. It marks all such 
bLlocks that receive control directly from a 
block in the selected loop as exit blocks. 
If only one exit block exists, that -Llock 
is the forward target of the loor. (The 
forward target must not be entered from a 
block not in the loop.) TARGET-IEKPT saves 
a pointer to the forward target for use in 
the subsequent processing of the loop. 


If the above condition is not met, the 
loop coes not have a defined forward 
target. 


—. 


Ointers to First and Last Blocks 


The pointers to the first and last 
blocks of the selected loop indicate to the 
text optimization and full register assign- 
ment routines where they are to initiate 
and terminate their processing. To make 
these pointers available, and loop selec- 
tion routine TARGET-IEKPT merely determines 
the first and last blocks of the selected 
loop and saves pointers to them for use in 
the subsequent processing of the loop. To 
determine the first and last blocks, 
TARGET-IEKPT searches the statement number 
chain for the first and last entries having 
the current loop number. The blocks asso- 
ciated with those entries are the first and 
last in the loop. 


Loop Composite Matrixes 


The loop composite matrixes, LMVS, LMVF, 
and LMVX, provide the text optimization and 
full register assignment routines with a 
summary of which operands are defined 
within the selected loop, which cperands 
are used within that loop, and which 
operands are busy-on-exit from that loop. 
(An operand is busy-on-exit from the loor 
if it is used before it is defined in any 
path along which control flows from the 
loor.) 
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The LMVS matrix indicates which operands 
are defined within the loop. The loop 
selection routine TARGET~IEKPT forms LMVS 
by combining, via an OR operation, the 
individual MVS fields in the statement 
number text entry of every block in the 
selected loop. 


The LMVF matrix indicates which operands 
are used within the loop. TARGET-IEKPT 
forms it by eombining, via an OR operation, 
the individual MVF fields in the statement 
number text entry of every block in the 
selected loop. 


The LMVX matrix indicates which operands 
are busy-on-exit from the selected loop. 
TARGET-IEKPT forms it during its search for 
the forward target of the loop. TARGET- 
IEKPT examines the text entries of each 
block that is not in the selected loop and 
that receives control from a block in that 
loop. Any operand in the text entries of 
such a block that is either only used in 
the block or used before it is defined is 
busy-on-exit from the loop. TARGET-IEKPT 
sets on the bit in the LMVX matrix that 
corresponds to the coordinate assigned to 
each such operand to reflect that it (i.e., 
the operand) is busy-on-exit from the loop. 


TEXT OPTIMIZATION - OPT=2 


The text optimization process of phase 
20 detects text entries within the loop 
under consideration that do not contribute 
to the loop's successful execution. These 
non-essential text entries are either com- 
pletely eliminated or are relocated to a 
block outside of the current loop. Because 
the most deeply-nested loops are presented 
for optimization first, the number of text 
entries in the most strategic sections of 
the object module will approach a minimum. 


The processing of text optimization is 
divided into three logical sections: 


e Common expression elimination optimizes 
the execution of a loop by eliminating 


unnecesSary re-computations of identic- 
al arithmetic expressions. 


e Backward movement optimizes the execu- 
tion of a loop by relocating to the 
back target computations essential to 
the module but not essential to the 
current loop. 


e Strength reduction optimizes the incre- 
mentation of DO indexes and the compu- 
tation of subscripts within the current 
loop. Modification of the DO increment 
may allow multiplications to be relo- 
cated into the back target. If the DO 
increment is not busy-on-exit from the 
loop, it may be completely replaced Ly 
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a new DO increment that becomes both a 
subscript value and a test value at the 
bkottom of the DO. 


The first two of the above sections are 
Similar in that they examine text entries 
in strict order of occurrence within the 
loor.. 


The last section does not examine indi- 
vidual text entries within the lcop; 
instead, the TYPES table, constructed prior 
to their execution, is consulted for opti- 
mMization possibilities. Furthermore, an 
interaction of entries in the TYPES table 
must exist before processing can proceed. 
The TYPES takle contains pointers to type 
3, 4, 5, 6, and 7 text entries. The 
various types, their definitions, and the 
section (Ss) of text optimization that pro- 
cess them are outlined in Table 4. Point- 
ers to type 1 and type 2 text entries are 
not entered into the TYPES table. The 
reason is that such types have already been 
processed during backward movement. 


The following text describes the proces- 
Sing performed by each of the sections of 
the text optimization. An example illus- 
trating the type of processing of each sec- 
tion is given in Appendix D. These 
examples should be referred to when reading 
the text describing the processing of the 
sections. 


Common Expression Elimination - OPT=2 


The okject of common expression elimina- 
tion, which is carried out by subroutine 
XPELIM-IEKOXM , is to eliminate any unne- 
cessary arithmetic expressions. This is 
accomplished by eliminating text entries, 
one at a time, until the entire expression 
disappears. An arithmetic text entry is 
unnecessary if it represents a value (cal- 
culated elsewhere in the loop) that may be 
used without modification. A value may be 
used without modification if, between 
appearances of the same computation, 
operands 2 and 3 of the text entry are not 
redefined. The following paragraphs dis- 
cuss the processing that occurs during com- 
mon expression elimination. 


Within the current loop, XPELIM-~IEKOXM 
examines each uncompleted block (i.e., a 
bklock that is not part of an inner loop) 
for text entries that are candidates for 
elimination. A text entry is a candidate 
if it contains an arithmetic, logical, or 
sukscript operator. Once a candidate is 
found, XPELIM-IEKQXM attempts to locate a 
matching text entry. A text entry matches 
the candidate if operand 2, operand 3, and 
the operator of that text entry are ident- 
ical to those of the candidate. If either 
operand 2 or 3 of the matching text entry 
is redefined between that text entry and 


®Table 4. Text Entry Types 


cS] oo a i Ea ee aa aa 1 
| Type | Definition | Processed by | 
|-------- {-~----~-~------~------------~----------------- |--~-------~-------------------- + 
| Type 1 | A text entry having an absolute constant" { | 
| | in either the operand 2 or operand 3 | Backward Movement | 
| | position. | | 
}-------- -------------------------------- +--+ + - +--+ -- === === === == === { 
| Type 2 | A text entry having stored constants? in | Backward Movement | 
| | both the operand 2 and operand 3 positions. | | 
}-------- }----~---------------------------------------- 4-------------------------------- { 
| Type 3 | An inert text entry (i.e., a text entry { | 
| | that is a function of itself and an addi- {| Strength Reduction | 
| tive constant; e.g., J=J+1). | | | 
|-------- }------------~----—--------------------------- {-------—--~--------------------- { 
| Type 4 | A subscript text entry. | | 
}-------- +--------------------------------------------- f--~---~---~--~------------------ { 
| Type 5 | A text entry whose operand 1 (a temporary) | | 
j 1s a function of a variable (or temporary) | Strength Reduction | 
| } and a constant, and whose operator is | | 
| | multiplicative (* or /). | 
}-------- }--------------------------------------------- $-------------------------------- { 
| Type 6 | A text entry whose operand 1 (a temporary) | | 
| J} is a function of a variable (or temporary) | Strength Reduction | 
| | and a constant, and whose operator is | | 
| | additive (+ or -). | | 
|-------- 4----------------~-------------—-------------- }--+----------------------------- { 
| Type 7 | A branch text entry | Strength Reduction | 
ee eat do + + +f 

| tAbsolute constants are those that agree with the definition of numerical constants as | 
| stated in the publication IBM System/360 Operating System: FORTRAN IV. | 
| 

{7A stored constant iS a variable that is not defined within a loop, and thus its value | 
| remains constant throughout execution of that loop. | 
ce ee er ee  te eeSP N ENnret E SROE OES Nn Rd ea ea PPR Ae EN TD en RS Oe oe OR RN aie CA ee me J 


the candidate, the match is not accepted. 
The search for the matching text entry 
takes place in the following locations: 


e In the same block as the candidate, 
between the first text entry and the 
candidate. 


e In a back dominator (see note) cf the 
block in which the candidate resides. 


Note: Only back dominators that are not 
elements of previously processed loops and 
that are within the confines of the current 
loop are considered. The first back 
dominator considered is the one nearest to 
the block being processed. The next consi- 
dered is the back dominator of the nearest 
back dominator, etc. 


When a matching text entry is found, 
XPELIM-IEKQOXM performs elimination in the 
following way: 


e If operand 1 of the matching text entry 
is not redefined between that text 
entry and the candidate, XPELIM-IEKQXM 
substitutes that operand for operand 2 
of the candidate and converts the 
operator to a store. 


Section 2: 


e If, on the other hand, operand 1 is 
redefined, XPELIM-IEKQXM generates a 
text entry to save the value of operand 
1 in a temporary and inserts this text 
entry into text immediately after the 
watching text entry. It then replaces 
operand 2 of the candidate with this 
temporary, and converts the operator to 
a store. 


e Finally, if operand 1 of the candidate 
is a temporary generated Ly phase 15, 
XPELIM-IEKOXM replaces all uses of the 
temporary with the new operand 2 of the 
candidate and deletes the candidate. 
Thus, the value of the matching text 
entry is propagated forward for possi- 
ble participation in another candidate. 
This provides the link to the next text 
item of the complete common expression. 


All text entries in the block under con- 
Sideration are processed in the previously 
described manner. When the entire block is 
processed, the next uncompleted Elock in 
the loop is selected and its text entries 
undergo common expression elimination. 

When all uncompleted blocks in the loop are 
processed, control is returned to the con- 


Discussion of Major Components 59 


trol routine of phase 20, which passes con- 
trol to the portion of phase 20 that con- 
tinues text optimization through backward 
movement. . 


The overall logic of common expression 
elimination is illustrated in Chart 11. An 
example of common expression elimination is 
given in Appendix D. 


Backward Movement - OPT=2 


Backward movement, which is performed by 
subroutine BACMOV-IEKQOBM, moves text 
entries from a loop to an area that is 
executed less often, the back target of the 
loop. During backward movement, each 
uncompleted block in the loop being pro- 
cessed iS examined for text entries that 
are candidates for backward movement. To 
be a candidate for backward movement, a 
text entry must: 


e Contain an arithmetic or logical 
operator. 


e Have operands 2 and 3 that are not 
defined within the loop. 


When a candidate is found, BACMOV-IEKQBM 
carries out backward movement of that can- 
didate in one of two ways: 


e If operand 1 of the candidate is not 
busy-on-exit from the back target of 
the loop and if operand 1 of the candi- 
date is not defined elsewhere in the 
loop, BACMOV-IEKQBM moves the entire 
candidate to the back target of the 
loop. (An operand is not busy-on-exit 
from the back target if that operand is 
defined in the loop before it is used.) 


e If operand 1 of the candidate is busy- 
on-exit from the back target of the 
loop or if it is defined elsewhere in 
the loop, BACMOV-IEKQOBM generates a 
text entry to perform the computation 
of the expression in the candidate and 
store the result in a new temporary. 
It moves this text entry to the end of 
the back target of the loop and then 
replaces the expression in the candi- 
date with operand 1, the new temporary, 
of the generated text entry. 


All the text entries in the block under 
consideration are processed in the pre- 
viously described manner. When the entire 
block is processed, the next uncompleted 
block in the loop is selected and its text 
entries undergo backward movement. When 
all uncompleted blocks in the loop are pro- 
cessed, control is returned to the control 
routine of phase 20, which passes control 
to the portion of phase 20 that continues 
text optimization through strength 
reduction. 
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The overall logic of backward movement 
is illustrated in Chart 12. An example of 
backward movement is given in Appendix D. 


Two additional optimization processes 
are performed concurrently with backward 
movement. They are the elimination of 
Simple stores and of arithmetic expressions 
that appear in text entries and are func- 
tions of constants. 


Elimination of Simple Stores: BACMOV- 
IEKQBM effects the removal of unnecessary 


Simple stores (i.e., text entries of the 
form "operand 1 = operand 2") from the 


klock that is currently undergoing backward 


movement. The following paragrarh 
describes the procesSing. 


BACMOV-IEKQOBM selects aS candidates for 
elimination any simple store in which 
operand 1 is a non-subscripted variakle. 
Pointers to the candidates are passed to 
SUBSUM-IEKQOSM which determines if elimina- 
tion iS indeed possible according to the 
conditions illustrated in Table 5. At the 
Same time, SUBSUM-IEKQOSM replaces all uses 
of operand 1 of the candidate with operand 
2 of the candidate in text entries between 
either: 


e The candidate and the first redefini- 
tion of either operand. 


e The candidate and the end of the block. 


BACMOV-IEKQBM then deletes those candidates 
so marked by SUBSUM-IEK@CSM. An example of 

Simple-store elimination is illustrated in 

Appendix D. 


Takle 5. Operand Characteristics That 
Permit Simple-Store Elimination 
ee Va ee ; SR a aL all a 1 
}Operand 1|]Operand 1|Orperand 2 |Cperand 1 | 
|Busy-on- |Redefined|Redefined |Used Below| 
JExit From|Below in |Before {|Operand 2 | 
| Block | Block |Operand 1 |Redefini- | 
| | | Definition | tion | 
|~---~---- +--------- {---------- {---------- { 
{1. No | No | No | X | 
}--------- {--------- 4---------- +~--------- { 
{}2. No | No | Yes | No | 
}--------- {---—-—- +---~------ $——-------~ { 
}3. No | yes | No | X | 
|~-------- {------—-- +---------- 4---------- { 
}4. No | Yes | Yes | No | 
}-----~--- --------- +---—------ ---~------ 
{5. Yes | Yes | No { X | 
--~--—~-- ¢----~----}------—--}----------4 
}6. Yes | Yes | Yes | No | 
eo rer reenter Bee ee eee 
|X = condition cannot exist because of | 
Jprevious characteristics of operands. 
Le hg NC a EE ee een EE ene eed eee erg me 4 


Elimination of Text Entry Expressions 


Involving Integer Constants: During the 
scan of a block for text entries to be 


moved to the back target, BACMOV-IEKOBM 
also checks for text entries whose opera- 
tors are arithmetic and whose operands 2 
and 3 are both integer constants. When 
such a text entry is found, BACMOV-IEKQBM 
eliminates the arithmetic expression in the 
text entry by: i 


e Operand 1 of the inert text entry is 
the variable appearing in the expres- 
Sion of the logical IF statement that 
controls the loop. 


If the loop is a candidate, REDUCE- 
IEKQSR implements strength reduction in one 
of two ways: 


If the constants in the inert text 


entry and the multiplicative text 


e Calculating the result of the 
expression. 


e Creating a new dictionary entry for the a. 
result, which is a constant. 


e Replacing the arithmetic expression 
with the result. b. 


The text entry is thereby reduced to a 
Simple store, which may be eliminated Ly 
Simple-store elimination. 


Strength Reduction - OPT=2 ex 


Strength reduction, which is performed 
by subroutine REDUCE-IEKOSR , optimizes 
loops that are controlled by logical IF 
statements. (DO loops are converted to 
loops controlled by logical IF statements 
during Phase 10 processing.) Such loops 
are optimized by modifying the expression 
(e.g., J220) in the IF statement; this 
enables certain text entries to be moved 
from the loop to the back target of the 
loop, an area executed less frequently. o 
Strength reduction processing is divided 
into two sections: 


e Elimination of multiplicative text. 
e Elimination of additive text. e. 


Both of these sections perform strength 

reduction, but each has a Separate set of 

criteria for considering a loop as a candi- £. 
date for reduction. However, the manners 

in which these sections implement reduction 

are essentially the same. 


Elimination of Multiplicative Text: To or 
eliminate multiplicative text, REDUCE- 


ITEKOSR examines the loop being processed to 
determine if it is a candidate for strength 
reduction. The loop is a candidate if: 


e The loop contains an inert text entry 
(a type 3 text entry). 


e Operand 1 of the inert text entry is 
used in another text entry (in the 
loop) whose operator indicates multi- 
plication and whose other used operand 
is a constant’? (a type 5 entry). 


en a cee a CE ee AS ne ee ce ag ee 


1This other text entry is referred to as a 2 
multiplicative text entry. 
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entry are both absolute constants, 
REDUCE-IEKQSR: 


Calculates a new constant (RK) 
equal to the product of the akso- 
lute constants. 


Generates another inert text entry 
and inserts it into the loop imme- 
diately after the original inert 
text entry. The additive constant 
in this text entry is kK. 


Modifies the expression in the 
logical IF by: 


(1) Replacing the branch variable 
(see note) with operand 1 of 
the generated inert text entry. 


(2) Replacing the branch constant 
(see note) with a constant 
equal to the product of the 
branch constant and K. 


Deletes the original inert text 
entry if operand 1 of that text 
entry is not busy-on-exit from the 
loop. 


Moves 
entry 
loop. 


the multiplicative text 
to the back target of the 


Replaces operand 1 of the multi- 
plicative text entry with operand 
1 of the generated inert text 
entry. 


Replaces the uses of operand 1 of 
the multiplicative text entry that 
remain in the loop with operand 1 
of the generated inert text entry. 


Note: The branch variakle is the 
variable in the expression of the 
logical IF that is tested to 
determine if the loop is to be 
reexecuted. The branch constant 
is the constant to which ‘the 
branch variable is compared. For 
example, in IF (J23) where J is 
the branch variable and 3 is the 
branch constant. 


If either of the constants in the 
inert text entry or the multiplicative 
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text entry is a stored constant, 
REDUCE-IEKOSR performs similar proces- 
Sing to that described above. Howev- 
er, prior to generating the inert text 
entry, it generates two additional 
text entries and places them into the 
back target of the loop. The first 
text entry multiplies the two con- 
stants. Operand 1 of this text entry 
becomes the additive constant in the 
generated inert text entry. The 
second text entry multiplies operand 1 
of the first generated text entry by 
the branch constant. Operand 1 of the 
second text entry becomes the new 
branch constant of the logical IF. 


If additional multiplicative text 
entries exist within the loop, the above 
process iS repeated. Repetitive processing 
of this type results in a number of 
generated inert text entries, which may be 
eliminated from the loop by the processing 
of the second section of strength 
reduction. 


Elimination of Additive Text: To eliminate 
additive text, REDUCE-IEKQSR examines the 
loop being processed to determine if it is 
a candidate for strength reduction. The 
loop is a candidate if: : 


e The loop contains an inert text entry 
(type 3). 


e Operand 1 of the inert text entry is 
used in the loop in another text entry 
whose operator indicates addition’ 


(type 6). 


If the loop is a candidate, the proces- 
Sing performed by REDUCE-IEKQSR to elimin- 
ate the additive text entry is essentially 
the same as that performed to eliminate a 
multiplicative text entry. 


| The overall logic of strength reduction 
is illustrated in Chart 13. An example 
Showing both methods of strength reduction 
is given in Appendix D. 


FULL REGISTER ASSIGNMENT - OPT=2 


During OPT=2 optimization, full register 
assignment iS carried out on module loops, 
rather than on the entire module, as is the 
case for OPT=1 optimization. Regardless of 
whether a loop or the entire module is 
being processed, the full register assign- 
ment routines operate essentially in the 
Same manner. However, the optimization 
effect of full register assignment, when 
carried out ona loop-by-loop basis, is 


eee ee ed 


1This text entry is referred to as an addi- 
tive text entry. 
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more fronounced. Because the most deeply- 
nested loops are presented for full regis- 
ter assignment first, the number of regis- 
ter loads in the most strategic sections of 
the object module approaches a minimum. 

The processing of a loop by full register 
asSignment differs from the processing of 
the entire module only in the area of glob- 
al assignment. An understanding of the 
processing performed on a loop, other than 
global assignment, can be derived from the 
previous discussion of full register 
assignment. (Refer to "Full Register 
Assignment - OPT=1"). Global assignment 
for a loop is described in the fcllowing 
text. 


When procesSing a loop, the glokal 
assignment routine (GLOBAS-IEKRGB) inco- 
rporates into the current loop, wherever 
possible, the global assignments made to 
items (i.e., operands and base addresses) 
in previously processed loops. It does 
this to ensure that the same register is 
assigned in both loops if an item eligible 
for global assignment in the current loop 
was globally assigned in a previously pro- 
cessed loop. 


Before the global assignment routine 
assigns an available register to the most 
active item of the current loop, it deter- 
Mines whether that item was globally 
assigned in a previously processed loop. 
(As global assignment is carried out on 
each loop, all global assignments for that 
loop are recorded and saved for use when 
the next loop is considered.) If the item 
was not globally assigned in a previously 
processed lcop, GLOBAS-IEKRGB assigns it 
the first available register. If the item 
wasS globally assigned in a previously pro- 
cessed loop, the global assignment routine 
then determines whether the register 
assigned to the item in the previously pro- 
cessed loop is currently available. If 
that register is available, GLOBAS-IEKRGB 
also glokally assigns it to the same item 
in the current loop. If the register is 
not available, the global assignment of 
that item in the previously processed loop 
cannot be incorporated into the current 
loop. GLOBAS-IEKRGB therefore assigns the 
item an available register different from 
that assigned to it in the previously pro- 
cessed loop. GLOBAS-IEKRGB selects the 
eligible item with the next highest activi- 
ty in the current loop and treats it in the 
Same manner. Processing continues in this 
fashion until the supply of eligible items 
or the supply of available registers is 
exhausted. 


As each global assignment is made to an 
active item, GLOBAS-IEKRGB checks to deter- 
Mine whether or not that item is busy-on- 
exit from the back target of the loop. If 
the item is busy-on-exit, GLOBAS-IEKRGB 


generates a text entry to load that item 
into the assigned register and inserts it 
into the back target of the loop. The load 
is required to guarantee that the item is 
in a register and available for subsequent 
use during loop execution. If the item is 
not-busy-on-exit, the load text item is not 
required. If any globally assigned item is 
defined within the loop and is also busy- 
on-exit from the loop, GLOBAS-IEKRGB 
generates a text entry to store that item 
on exit from the loop. The generated store 
is needed to preserve the value of such an 
operand for use when it is required during 
the execution of an outer loop. 


GLOBAS-IEKRGB records all global assign- 
ments made for the current loop for use in 
the subsequent updating scan (see "Full 
Register Assignment-OPT=1") and also for 
incorporation, wherever possible, into sub- 
sequently processed loops. 


BRANCHING OPTIMIZATION - OPT=2 


During OPT=2 optimization, branching 
optimization iS carried out in the same 
Manner as during OPT=1 optimization. After 
all loops have undergone full register 
assignment, BLS-IEKSBS iS given control to 
calculate the size of each block. When the 
Sizes of all blocks have been calculated, 
BLS-IEKSBS uses the block size information 
to determine the blocks that can be 
branched to by means of RX-format branch 
instructions. 


PHASE 25 


Phase 25 completes the production of an 
object module from the combined output of 
the preceding phases of the compiler. An 
object module consists of four elements: 


e Text information. 

e External symbol dictionary. 
e Relocation dictionary. 

e Loader END record. 


The text information (instructions and 
data resulting from the compilation) is in 
a relocatable machine language form. It 
may contain unresolved external symbolic 
cross references (i1.e., references to sym- 
bols that do not appear in the object 
module). The external symbol dictionary 
contains the information needed to resolve 
the external symbolic cross references 
appearing in the text information. The 
relocation dictionary contains the informa- 
tion needed to relocate the text informa- 
tion for execution. The END record informs 
the linkage editor of the length of the 
object module and the address of itS main 
entry point. 
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An object module resulting from a compi- 
lation consists of a single control sec- 
tion, unless common blocks are associated 
with the module. An additional control 
section is included in the module for each 
common block. 


The object module produced by Phase 25 
is recorded on the SYSLIN data set if the 
LOAD option is specified by the FORTRAN 
programmer, and on the SYSPUNCH data set if 
the DECK option is specified. If the LIST 
option is specified, Phase 25 develops and 
records on the SYSPRINT data set a pseudo- 
assembler language listing of the instruc- 
tions and data of the object module. If 
the MAP option iS Specified, phase 25 also 
produces a storage map. Error messages 
produced during phase 25 (if any) are also 
recorded on the SYSPRINT data set. 


TEXT INFORMATION 


Text information consists of the machine 
language instructions and data resulting 
from the compilation. Each text informa- 
tion entry (a TXT record) constructed by 
phase 25 can contain up to 56 bytes of 
instructions and data, the address of the 
instructions and data relative to the 
beginning of the control section, and an 
indication of the control section that con- 
tains them. A more detailed discussion of 
the use and format of TXT records is given 


in the puklication IBM System/360 Operating 
System: Linkage Editor, Program Logic 


Manual. 


The major portion of phase 25 processing 
is concerned with text information con- 
Struction. In building text information, 
phase 25 oktains each item that is to ke 
placed into text information, converts the 
item to machine language form wherever 
necessary, enters the item into a TXT rec- 
ord, and places the relative address of the 
item into the TXT record. 


Phase 25 assigns relative addresses by 
reans of a location counter, which iS con- 
tinually updated to reflect the location at 
which the next item is to be placed into 
text information. Whenever phase 25 begins 
the construction of a new TXT record, it 
inserts the current value of the location 
counter intc the address field of the TXT 
record. The address field of the TXT rec- 
ord thereby indicates the relative address 
of the instructions and data that are 
placed into the record. 


Figure 9 shows the layout of storage 


that Phase 25 assumes in setting up text 
inforraticn. 
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eFigure 9. Storage Layout for Text Information Construction 


Phase 25 constructs text information by: 


e Reserving dictionary entries for the 
referenced statement numbers of the 
module. 

e Completing the processing of the adcon 
table entries and entering the resul- 

tant entries into TXT records. 

e Generating the prologue and epilogue 
instructions for a subprogram and 
secondary entry points and entering 
these instructions into TXT records. 

e Converting phase 15/20 standard text 
into System/360 machine code and enter- 
ing the code into TXT records. 


Chart 20 shows the logic of phase 25 
processing, down to, but not including, 
conversion of text to machine code. 
Address Constant Reservation 

Before it constructs text information, 


Subroutine MAINGN-IEKTA reserves address 
constants for the referenced statement num- 
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bers of the module and for the statement 
numbers appearing in computed GO TO state- 
ments. The address constants are reserved 
so that the relative addresses of the sta- 
tements associated with such statement nun- 
bers can be recorded, and subsequently 
oktained during execution of the object 
module, when branches to those statements 
are required. 


To reserve address constants for state- 
ment numbers, subroutine MAINGN-IEKTA scans 
the chain of statement number entries in 
the statement number/array table. For each 
encountered statement number that is 
referred to MAINGN-IEKTA inserts a base and 
displacement into the associated statement 
number entry. When the text representation 
of that statement number is encountered, a 
relative address is placed in the statement 
number entry. 


Note: If branching optimization is being 
implemented, MAINGN-IEKTA only assigns a 
base and displacement for statement numbers 
that are associated with text blocks that 
can not be branched to via RX-format branch 
instructions. 





After all statement numbers are pro- 
cessed, bases and displacements are like- 
wise assigned for the statement numbers 
appearing in computed GO TO statements. 
MAINGN-IEKTA Scans the branch table chain 
(refer to Appendix A, “Branch Table"), and 
assigns a base and displacement for each 
branch table entry. MAINGN-IEKTA does not 
record pointers to the address constants 
set aside for the actual statement numbers 
of the computed GO TO statements in their 
associated standard branch table entries. 
The values to be placed into the address 
constants for statement numbers in computed 
GO TO statements are also determined during 
text conversion. 


Main Program Entry Coding 


To generate main program entry coding, 
phase 25 works with the FSD subroutine IEK- 
TLOAD. After IEKTLOAD saves the contents 
of the general registers and loads reserved 
registers with their associated addresses, 
subroutine ENTRY-IEKTEN (phase 25) 
generates instructions that perform the 
following functions: 


e Load register 15 with the address of 
ITHCFCOMH. 


e Branch and link to subroutine IBFINT 
(arithmetic interruption subroutine of 
IHCFCOMH) so that it can set the inter- 
ruption mask. 


e Load register 13 from register 4. 
e Branch to apparent entry point. 


e Load register 15 with the address of 
IHCFCOMH. 


e Branch and link to STOP entry point in 
ITHCFCOMH. 


e Generate constant for STOP QO. 


e Set up a save area that receives the 
contents of the main program registers, 
if a subprogram is called. 


e Set up the address constants to be 
loaded into the reserved registers. 


Note: At execution time, subroutine IBFINT 
is given control to set the interruption 
mask. 
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Text Conversion 


Phase 25 converts intermediate text into 
Operating System/360 machine code. (The 
text conversion process is controlled by 
subroutine MAINGN-IEKTA.) In converting 
the text, phase 25 obtains each text entry 
and, depending upon the nature of the 
Operator in the text entry, passes control 
to one of six processing paths to convert 
the text entry. 


The six processing paths are: 


Statement Number Processing. 
I/O Statement Processing. 
CALL Statement Processing. 
Code Generation. 

RETURN Statement Processing. 
END Statement Processing. 


The logic of text conversion is illus- 
trated in Chart 21. 


STATEMENT NUMBER PROCESSING: When the 
operator of the text entry indicates a 
statement number, MAINGN-IEKTA passes con- 
trol to subroutine LABEL-IEKTLB. LABEL- 
IFKTLB then inserts the current value of 
the location counter, which is the relative 
address of the statement associated with 
the statement number, into the statement 
number entry. All branches to that state- 
ment are effected through the use of the 
relative address for that statement number. 


Note: If branching optimization is being 
implemented, only statement number that can 
not be branched to via RX format branch 
instructions (1.e., statement numbers that 
are not within the range of registers 13, 
11, 10, and 9) are processed as described 
above. 


After the relative address has been 
placed into the statement number entry, 
Sukroutine LABEL-IEKTLB determines if that 
Statement number appears in a computed GO 
TO statement. If it does, LABEL-IEKTLB 
also inserts the relative address into the 
appropriate field of the branch table 
entry, or entries, for that statement num- 
ber. The relative address recorded in the 
branch takle entry is placed into the 
storage reserved for it within text infor- 
Mation (refer to “END Statement Proces- 
Sing") when the text representation of the 
END statement is encountered. 


I/O STATEMENT PROCESSING: When the opera- 
tor of the text entry indicates an I/0 
Statement, an I/O list item, or the end of 
an I/O list, MAINGN-IEKTA passes control to 
subroutine IOSUB-IEKTIS, which generates an 
appropriate calling sequence to IHCFCOMH to 
perform, at object-time, the indicated 
operation. 
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The calling sequence generated for an 
I/O statement depends on the type of the 
Statement (e.g., READ, BACKSPACE). The 
calling sequence generated for an I/O list 
item depends on the I/0 statement type with 
which the list item is associated and on 
the nature of the list item, i.e., whether 
the item is a variable or an array. The 
calling sequence generated for an end of an 
I/O list depends on whether the end I/0 
list operator signals: 


e The end of an I/O list associated with 
a READ/WRITE requiring a FORMAT 
statement. 


e The end of an I/O list associated with 
a READ/WRITE not requiring a FORMAT 
Statement. 


Once the calling sequence is generated, 
subroutine IOSUB-IEKTIS enters it into TXT 
records. — 


CALL STATEMENT PROCESSING: When the opera- 
tor of the text entry indicates a CALL 
statement, MAINGN-IEKTA passes control to 
subroutine FNCALL-IEKVFN to generate a 
Standard direct-linkage calling sequence, 
which uses general register 1 as the argu- 
ment register. The argument list is 
located in the adcon table in the form of 
address constants. Each address constant 
for an argument contains the relative 
address of the argument. FNCALL-IEKVFN 
enters the calling sequence into TXT 
records. 


CODE GENERATION: Code generation converts 
text entries having operators other than 
those for statement numbers and ENTRY, 
CALL, I/0, RETURN, and END statements into 
System/360 machine code. To convert the 
text entry, code generation uses four 
arrays and the information in the text 
entry. The four arrays are: 


e Register array. ThisS array is reserved 
for register and displacement 
information. 


e Directory array. This array contains 
pointers to the skeleton arrays and the 
bit strip arrays associated with opera- 
tors in text entries that undergo code 
generation. 


e Skeleton array. A skeleton array 
exists for each type of operator in an 
intermediate text entry that is to be 
processed by code generation. The 
skeleton array for a particular opera- 
tor consists of all the machine code 
instructions, in skeleton form and in 
proper sequence, needed to convert the 
text entry containing the operator into 
machine code. These instructions are 
used in various combinations to produce 
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the desired object code. (The skeleton 
arrays are shown in Appendix C.) 


e Bit strip array. A bit strip array 
exists for each type of operator in a 
text entry that is to undergo code 
generation. One strip is selected for 
each conversion involving the operator. 
The bits in each strip are preset 
(either on or off) in such a fashion 
that when the strip is matched against 
the skeleton array, the strip indicates 
the combination of instructions that is 
to be used to convert the text entry. 
(The bit strip arrays are shown with 
their associated skeleton arrays in 
Appendix C.) 


In code generation, the actual base 
registers and operational registers (i.e., 
registers in which calculations are to he 
performed), assigned by phase 20 to the 
orerands of the text entry to be converted 
to machine code, are obtained from the text 
entry and placed into the register array. 
Any displacements needed to load the kase 
addresses of the operands are also placed 
into the register array. The displacerents 
referred to in this context are the dis- 
placements of the base addresses of the 
operands from the start of the adcon table 
that contains the base addresses. These 
displacements are obtained from the infor- 
mation table entries for the operands. 

This action is taken to facilitate subse- 
quent processing. 


The operator of the text entry to be 
converted is used as an index to the direc- 
tory array. The entry in this directory 
array, which is pointed to by the operator 
index, contains pointers to the skeleton 
array and the bit strip array associated 
with the operator. 


The proper bit strip is then selected 
from the bit strip array. The selection 
depends on the status of operand 2 and 
operand 3 of the text entry. This status 
is set up Ly phase 20 and is indicated in 
the text entry by four bits (see Appendix 
A, “Phase 20 Intermediate Text Modifica- 
tions"): the first two bits indicate the 
status of operand 2; the second two bits 
indicate the status of operand 3. 


The status of operand 2 and/or operand 3 
can ke one of the following: 


00 The operand iS in main storage and 
is to remain there after the present 
code generation. Therefore, if the 
oferand is loaded into a register 
during the present code generation, 
the contents of the register can be 
destroyed without concern for the 
operand. 


01 ‘The operand is in main storage and 
is to be loaded into a register. 
The operand is to remain in that 
register for a subsequent code 
generation; therefore, the contents 
of the register are not to be 
destroyed. 


10 The operand is in a register as a 
result of a previous code genera- 
tion. After the register is used in 
the present code generation process, 
its contents can be destroyed. 


11 The operand iS in a register and is 
to remain in that register for a 
subsequent code generation. The 
contents of the register are not to 
be destroyed. 


This four bit status field is used as an 
index to select a bit strip from the bit 
Strip array associated with the operator. 
The combination of instructions indicated 
in the bit strip conforms to the operand 
Status requirements: i.e., if the status 
of operand 2 is 11, the generated instruc- 
tions make use of the register containing 
operand 2 and do not destroy its contents. 
The combination, however, excludes base 
load instructions and the store into 
operand 1. 


Once the bit strip is selected, it is 
moved to a work area. The strip is modi- 
fied to include any required base load 
instructions. That is, bitsS are set on in 
the appropriate positions of the bit strip 
such that, when the strip is matched to the 
Skeleton array, the appropriate instruc- 
tions for loading base addresses are 
included in the object code. The skeletons 
for these load instructions are part of the 
Skeleton array. 


The code generation process determines 
if the base address of operand 2 and/or 
operand 3 must be loaded into a register by 
examining the status of these base 
addresses in the text entry. Such status 
is indicated by four bits: the first two 
bits indicate the status of the base 
address of operand 2; the second two bits 
indicate the status of the base address of 
operand 3. If this status field indicates 
that a base address is to be loaded, the 
appropriate bit in the bit strip is set on. 
(The bit to be operated upon is known, 
because the format of the skeleton array 
for the operator is known.) 


Before the actual match of the bit strip 
to the skeleton array takes place, the code 
generation process determines: 


e If the base address of operand 1 must 
be loaded into a register. 
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e If the result produced Ly the actual 
machine code for the text entry is to 
be stored into operand 1. 


This information iS again indicated in the 
text entry by four bits: the first two 
bits indicate the status of the base 
address of operand 1; the second two bits 
indicate whether or not a store into 
operand 1 is to be included as part of the 
object ccde. If the base address of 
operand 1 is to be loaded and/or if operand 
1 is to be stored into, the appropriate 

kit (Ss) in the kit strip is set on. 


The bit strip is then matched against 
the skeleton array. Each skeleton instruc- 
tion corresponding to a bit that is set on 
in the bit strip is obtained and converted 
to actual machine code. The operation code 
of the skeleton instruction is modified, if 
necessary, to agree with the mode of the 
operand of the instruction. The mode of 
the operand is indicated in the text entry. 
The symbolic base, index, and operational 
registers of the skeleton instructions are 
replaced by actual registers. The base and 
operational registers to be used are con- 
tained in the register array. If an 
operand is to be indexed, the index regis- 
ter to be used is obtained, (The index 
register is saved during the processing of 
the text entry whose operand 1 represents 
the actual index value to be used.) The 
displacerent of the operand from its hkase 
address, if needed, is obtained from the 
information takle entry for the operand. 
(The contents of the displacement field are 
added to this displacement if a subscript 
text entry is being processed.) These ele- 
ments are then combined into a machine 
instruction, which is entered into. a TXT 
record. (If the skeleton instruction that 
is being converted to machine code is a 
base load insStruction, the base address of 
the operand is obtained from the okject- 
time adcon table. The register (13) con- 
taining the address of the adcon table and 
the displacement of the operand's kLase 
address from the beginning of the adcon 
table are contained in the register array.) 


Branch Processing: The code generation 
portion of phase 25 generates the machine 
code instructions to complete branching 
Optimization. The processing performed by 
code generation, if branching optimization 
is being implemented, is essentially the 
same as that performed to produce an object 
module in which branching is not optimized. 
However, before a skeleton instruction 
(corresponding to an on bit in the selected 
and modified bit strip) is assembled into a 
machine code instruction, code generation 
determines if that instruction either: 
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e Loads into a register the address of an 
instruction to which a branch is to be 
made and which is displaced less than 
4096 bytes from the address in a 
reserved register’. 


e Is an RR-format branch instruction that 
branches to an instruction that is dis- 
placed less than 4096 bytes from the 
address in a reserved register?. 


Note: A load candidate usually immediately 
precedes a branch candidate in the skeleton 
array. 


Code generation determines if the 
instruction to be branched to is displaced 
less than 4096 bytes from an address ina 
reserved register by interrogating an indi- 
cator in the statement number entry for the 
statement number associated with the block 
containing the instruction to be branched 
to. This indicator is set by phase 20 to 
reflect whether or not that block is dis- 
placed less than 4096 bytes from an address 
in a reserved register. 


The completion of branching optimization 
proceeds in the following manner. If a 
skeleton instruction corresponding to an on 
bit in the bit strip is a load condidate, 
it is not included as part of the instruc- 
tion sequence generated for the text entry 
under consideration. If a skeleton 
instruction corresponding to an on bit in 
the bit strip is a branch candidate, it is 
converted to an RX-format branch instruc- 
tion. The conversion is accomplished by 
replacing operand 2 (a register) of the 
‘branch candidate with an actual storage 
address of the form D (0,Br) D represents 
the displacement of the instruction (to be 
branched to) from the address that is in 
the appropriate reserved register (Br). 


If the instruction to be branched to is 
the first in the text block, both the dis- 
placement and the reserved register to be 
used for the RX-format branch are obtained 
from the statement number entry associated 
with the block containing the instruction. 
(This information is placed into the state- 
ment number entry during phase 20 
procesSing.) 


If the instruction to be branched to is 
one that is subsequently to be included as 
part of the instruction sequence generated 


A EN RD ec EE ED RD cee ee Ene <i cme ever ape eee ee oe 


1This type of text entry is subsequently 
referred to as a load candidate. 

“This type of text entry is subsequently 
referred to aS a branch candidate. 
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RETURN STATEMENT PROCESSING: 


END STATEMENT PROCESSING: 


for the text entry under consideration?, 
the displacement of the instruction from 
the address in the appropriate reserved 
register is computed and used as the dis- 
placement of the RX-format branch instruc- 
tion. The reserved register used in such a 
case is the one indicated in the statement 
number entry associated with the block con- 
taining the text entry currently being pro- 
cessed by code generation. 


When the 
operator of the text entry indicates a 
RETURN statement, MAINGN-IEKTA passes con- 
trol to subroutine RETURN-IEKTRN, which 
generates a branch to the epilogue. The 
epilogue address is obtained from the suk- 
program save area. The address of the epi- 
logue is placed into the save area during 
the execution of either the subprogram main 
entry coding or the subprogram secondary 
entry coding (refer to the section 
“Initialization Instructions"). 


When the opera- 
tor of the text entry indicates an END 
statement, MAINGN-IEKTA passes control to 
sukroutine END-IEKUEN, which completes the 
processing of the module by entering the 
address constants (i.e., relative 
addresses) for statement numbers and state- 
ment numbers appearing in computed GO TO 
Statements into text information and by 
generating the END record. 


Subroutine END-IEKUEN calls ENTRY-IEKTEN 
to determine if the program being compiled 
is a main program or a subprogram and to 
take the appropriate action. If it is a 
Subprogram, ENTRY-IEKTEN calls EPILOG- 
IEKTEP and PROLCG-IEKTPR. (Refer to "Pro- 
logue and Epilogue Generation.") If it isa 
Main program, ENTRY-IEKTEN generates code 
to call IBFINT (arithmetic interruption 
subroutine of IHCFCOMH) and generates a 
branch to the appropriate place in text. 

If there are secondary entry points, text 
is scanned to determine where they are 
located. An epilogue and prologue are 
generated for each entry point with a 
branch to the corresponding point in the 
object code. ENTRY-IEKTEN returns control 
to END-IEKUEN. 


END-IEKUEN places TXT and RLD records in 
the object module for the following: adcon 
for the save area, adcon for the Epilogue, 
adcon for register 12, if needed, adcons 
for branch tables, adcons for parameter 
lists, and adcons for ‘B*' block labels. 
END-IEKUEN generates TXT information for 
each temporary. END-IEKUEN calls IEND (FSD 
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3Skeleton arrays for certain operators con- 
tain RR format branch instructions that 
transfer control to other instructions of 
that skeleton. 





entry point) to generate the loader END 
record which must be the last record of the 
object module. Its functions are to signal 
the end of the object module and to inform 
the linkage editor of the size (in bytes) 
of the control section and the address of 
the main entry entry point of the control 
section. END-IEKUEN then returns control 
to the FSD through MAINGN-IEKTA. 


Storage Map Production 


As a user option, subroutine IEKGMP pro- 
duces a storage map of the symbols used in 
the source program. The map contains the 
following information: 


Name 
Tag S - The variable appeared to the 
left of an equal Sign in the 


source program. (stored 
into) 


The variable appeared to the 
right of an equal sign in the 
source program. (fetched) 


The variable was used aS an 
argument. 


The variable appeared ina 
COMMON statement. 


The variable appeared in an 
EQUIVALENCE statement. 

XR - The variable is a call-by- 
name parameter to the source 
program. 


The entry is a subroutine or 
function to the source 
program. 


The variable is the name of 
an arithmetic statement 
function. 


ASF- 


Identifies the type of variable -- 
Type * length -- in bytes. 


Type 


Add. Is the relative address of the 
variable within the object module 


(in hex). 


The total size of the object module is 
- also given. 


A map of each common block is generated 
to give the relative location of each 
variables in that common block. .A map of 
variable equivalenced into common is also — 
provided. | : 


In addition, TENTXT-IEKVTN generates a 
map of statement numbers. 
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Prologue and Epilogue Generation 


Phase 25 generates the machine code: 
(1) to transmit parameters to a subprogran, 
and (2) to return control to the calling 
routine after execution of the subprogram. 
Parameters are transmitted to the subpro- 
gram by means of a prologue. Return is 
made to the calling routine by means of an 
epilogue. Prologues and epilogues are pro- 
vided for subprogram secondary entry points 
as well as for the main entry point. 


Prologue: A prologue (generated by subrou- 
tine PROLOG-IEKTPR) is a series of load and 
store instructions that transmit the values 
of “call by value" parameters and the 
addresses of “call by name“ parameters to 
the subprogram. (These parameters are 
explained in the publication IBM System/360 


Operating System: FORTRAN IV.) 


When subroutine PROLOG-IEKTPR generates 
a prologue, it enters the prologue into TXT 
records and inserts its relative address 
into the address constant reserved for the 
prologue address during the generation of 
initialization instructions. 
Epilogue: An epilogue (generated by sub- 
routine EPILOG-IEKTEP) is a series of 
instructions that (1) return to the calling 
routine the values of “call by value" 
parameters (if they are stored into or used 
as arguments), (2) restore the registers of 
the calling routine, and (3) return control 
to the calling routine. (If “call by 
value" parameters do not exist, an epilogue 
consists of only those instructions 
required to restore the registers and to 
return control.) 


When subroutine EPILOG-IEKTEP generates 
an epilogue, it enters the epilogue into 
TXT records and inserts its relative 
address into the address constant reserved 
for the epilogue address during the genera- 
tion of initialization instructions. (When 
phase 25 encounters the text representation 
of a RETURN statement, a branch to the epi- 
logue is generated.) 


PHASE 30 


Phase 30 records (on the SYSPRINT data 
set) appropriate messages for syntactical 
errors encountered during the processing of 
phases 10 and 15; its overall logic is 
illustrated in Chart 22. AS errors are 
encountered by these phases, error table 
entries are created and placed into an 
error table. Each such entry consists of 
two parts: the first part contains either 
an internal statement number, if the entry 
is for a statement that is in error, a dic- 
tionary pointer to a variable, if the entry 
is for a variable that is in error, or an 
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actual statement number, if the entry is 
for an undefined statement number; the 
second part contains a message number. (If 
the error cannot be localized to a particu- 
lar statement, no internal statement number 
is entered in the error table entry. Phase 
30 simulates the internal statement number 
- with a zero.) 


Message Processing 


Using the message number in the error 
table entry multiplied by four, phase 30 
locates, within the message pointer takle 
(refer to Appendix A, “Diagnostic Message 
Tables“), the entry corresponding to the 
message number. This message pointer table 
entry contains (1) the length of the mes- 
Sage associated with the message number, 
and (2) a pointer to the text of the mes- 
Sage associated with the message number. 
After phase 30 obtains the pointer to the 
message text, it constructs a parameter 
list, which consists of: 


e Fither the internal statement number, 
dictionary pointer, or statement number 
appearing in the error table entry. 

e A pointer to the message text asso- 
ciated with the message number. 

e The length of the message. 

e The message number. 

e The error level. 


70 


Having constructed the parameter list, 


phase 30 calls subroutine MSGWRT-IEKP31 


which writes the message on the SYSPRINT 
data set. After the message is written, 
the next error table entry is obtained and 
processed as described above. 


As each error table entry is being pro- 
cessed, the error level code (either 4 or 
8) associated with the message number is 
oktained from the error code table (GRA- 
VERR) by using the message number in the 
error table entry as an index. The error 
level code indicates the seriousness of the 
encountered error. (See the publication 


IBM System/360 Operating System: FORTRAN 
IV_(H) Programmer's Guide for explanations 


of all the messages the compiler 
generates.) The obtained error level code 
is saved for subsequent use only if it is 
greater than the error level codes asso- 
ciated with message numbers appearing in 
previously processed error table entries. 
Thus, after all error table entries have 
been processed, the highest error level 
code (either 4 or 8) has been saved. The 
saved error level code is passed to the FSD 
when phase 30 processing is completed. 
This code is used by the FSD to determine 
whether or not the compilation is to be 
deleted. 
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e Table 6. FSD Subroutine Directory 


[Subroutine] sti—(<‘é!O!O!O!O!!.OC€RUnctiONlllv6€6€©€©€©™©™€™UU 
apegers I ecccoruy excnen (seen Ge integers by@eegevs, =C~<“‘“i< i C'*‘“<CSCSCSCS*S 
| IEKAFP | 

| IEKAAA | Communication table. 

| IEKAAD | Internal adcon table. 

| IEKAAO00 | Initializes compiler processing and calls the phases for execution. Entry 
| {| point for compiler. 

! ITEKAAO1 | Default options, & DDNAMES for compiler, PAGEHEAD. 

| IEKAA9 | Deletes compilation if requested. 

| IEKAER | Error message table. 

| IEKAGC | Allocates and keeps track of main storage used in the construction of the 
| | information table and for collecting text entries. 

| IEKAPT | Maximizing service routine for integers and reals, diagnostic trace rou- 

| | tine; bypasses IEKFCOMH for some error messages. 

| IEKATB | Provides diagnostic dumps of internal text and tables. 

| IEKATM | Timing routine. 

| ITEKFCOMH | Controls formatted compile-time I/C. (Corresponds to IHCFCOMH; refer to 

| | Appendix E.) ) 

| ITEKFIOCS | Interface between compiler, IEKFCCMH, and QSAM. 

| IEKTDC | Listing routine. 

| IEKTLOAD \ Builds ESD, TXT, RLD, and loader END records. 


74 


e Chart, 03. 


ENTRY IS TO 
DISEATCHER 
( IFKCIN). 


ITEKCIN 


He Rete he A] deo te ake te ke 


FRCM 
FSD 


he We a ta a a ok ok 


* 
+ 
* 


C2 
* 


¢@¢é@e86eseau_peteeoge#eeotve 668 #@ &@ FSF HFS HULHDUDULCUMGDUSEDULUDUCUHMDULULGQDU™UM BCcCUHMmUMOCUC HU OULU OOUh hUh hh hUchOUhhU Oh 


Phase 10 Overall Logic 


2eewpmreneaewenavenrenwesaawseteesnmneenvwsnmwenstaeanweeveaveseaenrseseeestsnve eae eaeteemeenwmenveeenssese 8 


anes 
* 


= 
ioe 


MR KD mK eK 
* 


oy 
* * 
INITIALIZE : 
* te 
eT eCrrtrrrL see es : 
KK | 
* x | 
* B2 *->| 
* * 
KOK 


V 
HR KKB DK KK OK 


* GETCD-IEKCGC * 
Ra KKK KM HR 


*READ,LIST, AND * 
*PREPARE SOURCE * 
* STATEMENT * 
HR ROR RK ROK EK EK 


DISPATCHER 


IFKCDP 
LINES. 


CALLS THE P 


(DSPTCH- 
) IS WITHIN DOTTED 
DSETCH-IEKCDE 

REPARATORY 


SUBROUTINE. 


BRKKKN ZIRE KEKE KKK 
* XCLASS-IEKDCL * 
KKK KK HK 
>*PROCESS STATE- * 
* MENT NUMBER * 
* (IF PRESENT) * 
RE RKK KK KKK EK KKK KK 


ta ee ee 


HEREC RARER EKER E 
* LETERMINE x 
* ROUTE FROM * 
*CLASSIFICATION * 
~ CODE * 
* * 
Pe ESE LESS SE ESS SS 


a=eaweseesvwveweanmetsaetcndeaevenaegmwenmaswenwematmendopseveaeztenwrwneenwewaseanenweeeweaenete 


V 
HEREEY) IRREKE RAKE EK 
* 


PRCCESS 
SOURCE 
STATEMENT 


ERKKKEEKK KKK EK 


HH He 


* 
* 
* 
* 
* 
* 


Section 2: 


SEE TABLE 8 FOR A 
DESCRIPTION OF THE 
SUBROUTINES OF 
PHASE 10. 


#e8eeeeee8ses8eoet6 #66 8&8 6 6 ot G©G@O Fe wesw sees eo 8 se oe & Bw 


TABLE 7 


KEKKEYRKKEKK KKH 


TO PHASE 15 
VIA FSD 


RR KEKE RK KK KKK 


* 
x 
* 


Discussion of Major Comronents 


75 


e Chart O44. 
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e Table 8. Phase 10 Subroutine Directory 


1 Top et ae i a oT eee ee a ee ce ge meen Weep se, gq MP pe Ce Fy Oe Se aN LTE OTe ES ge Se 1 


Subroutine | Type 


| : * Function | 


jJentry placement) 


| 
DSPTCH-IEKCDP|Dispatcher, Key Word, and 
JUtility (entry placement) 


GETCD-IEKCGC |Preparatory 


GETWD-IEKCGW [Utility (collection) 


ITEKKOS Utility (table entry) 


KH 
ry 
x 
rad 
aw 
ep) 


{Miscellaneous 


LABTLU-IEKCLT|Utility (entry placement) 


| | 
PH10-IEKCAA [Utility (common data area) 


PUTX-IEKCPX [Utility (entry placement) 
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| CSORN-IEKCCR |Utility (collection, conversion, |Entry IEKCCR directs the entering of | 


{variables and constants into the infor- 
[mation table. 


JEntry IEKCLC converts integer, real, and 
|complex constants to their binary 
| equivalents. 


{Entry IEKCS1 places variable names on 
}full word boundaries for comparison t 
Jother variable names. : 


[Entry IEKCS2 places dictionary entries 
|constructed for variables and constants 
jof the source module into the informa- 
{tion table. 


JEntry IEKCS3 combines the functions of 
jentries IEKCS1 and IEKCS2 (above) for 
jvariable names. 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
{Controls phase 10 procesSing, passes | 
jcontrol to the preparatory subroutine to] 
|prepare the source statement, determines] 
|from the code assigned to the statement | 
Jwhich subroutine is to continue proces- | 
{sing the statement, and passes control | 
Jto that subroutine. | 
|Develops intermediate text representa-_ | 
{tions of the BLOCK DATA, CCNTINUE, | 
JEXTERNAL, and IF statements and that | 
|e~ortion of a statement function to the | 
Jleft of the equal sign, builds informa- | 
jtion takle entries for the operands of | 
{these statements, and analyzes these. | 
{statements for syntactical errors. | 
|Builds error table entries for the syn- | 
{tactical errors detected by phase 10 and| 
Jelaces ther in the error table. 
| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

| 

J 


jReads, lists (if requested), packs, and 
{classifies each Source statement. 


}Obtains the next group of characters in 
{the source statement being processed. 


{Assigns coordinates based on usage count 
Jto variables and constants. 

| | 
{Writes XREF buffer on SYSUT2. 


|Places statement number entries into the 
{information table. 


| 
|Phase 10 COMMON area. 


|Places text entries into the appropriate 


_|sub-blocks, obtains the next oferator 


{from the source statement, and places 
|the operator in the text entry work 


(Continued) 


Fecal 8. . Phase 10 Subroutine Directory (Continued) 


au ean s Sas ara a aR aa aa aaa a a a a IG a a eam | 
| Subroutine | Type | Function | 
|STALL-IEKGST [Utility (table entry and text {Generates entry code for object module, 

| generation) {translates format text to object code, 


| |generates object code for literal data 
Jtext, processes equivalence entries 
| (those that were equivalenced before 
[being dimensioned), sets aside space in 
{the object module for the problem pro- 
|gram save area and for computed GO TO 
}cranch tables, checks for undefined 
{statement numbers, rechains variables, 
{assigns coordinates based on usage 
}count, processes common entries, and 
|rrocesses equivalence entries. 


| 
| 
| 
| | 
| | 
| | 
| 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
XARITH-IEKCAR |Arithmetic {Controls the procesSing of arithmetic | 
| |statements, CALL arguments, expressions | 
| Jin IF statements, I/O list items, the | 
| |expression portion of a statement func- | 
| |tion, and the branch tables of an arith-] 
| |metic IF statement. Builds information | 
| {table entries for the operands of the | 
| |previously mentioned statements, and | 
| {analyzes the statements for syntactical | 
| |errors. | 
| | | 
XCLASS-IEKDCL|Utility (text generation) [Controls the processing of source and | 
| | |compiler-generated statement numbers, j 
| |generates the intermediate text required] 
| jto increment a DO index and to compare | 
| {the index with its maximum value, and | 
| |processes CALL arguments of the form & | 
| |lakel. | 
| | | 
XDATYP-IEKCDT|Key Word (table entry and text) |Develops intermediate text representa- | 
| {tions of DATA and TYPE statements, | 
| |constructs information takle entries for| 
| |the operands of DATA and TYPE state- | 
| [ments, and analyzes these statements for| 
| [syntactical errors. | 
| | | 
|Key Word (table entry and text) |Develops the intermediate text ‘and | 
| {information table entries for the DO | 
[ [statement and implied DOS appearing in | 
| |I/C statements and analyzes them for | 
| |syntactical errors. | 
| | | 
|Key Word (table entry and text) |Develops intermediate text representa- | 
| {tions of the GO TO (unconditional, | 
| jassigned, and computed) statements, con-| 
| [structs information table entries for | 
| |the operands of these statements, and | 
| Janalyzes these statements for syntactic-—| 
| |al errors. | 
| | l 
[Key Word (table and text entry) |Develops intermediate text representa- | 
| Jtions of I/O statements, constructs | 
| [information table entries for their | 
| |operands, and analyzes I/C statements | 
| [for syntactical errors. (I/O list items] 

| j|are processed by subroutine 
| | XARETH- ITEKCAR.) l 
Sg ae a ag et J 


(Continued) 


XDO-IEKCDO 


|/XGO-LEKCGO 


XLOOP-IEKCIO 
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eTable 8. Phase 10 Subroutine Directory (Continued) 


Cr a a8 gg ee ee GEN eS geet Tee RE GN re re me RO ee A Ia ete PE oe WE gE y ee eT, ery 


|Subroutine | Type 


|— 
| XSPECS-IEKCSP|Key Word (table entry) 


XSUBPG-IEKCSR|Key Word (table and text entry) 


XTNDED-IEKCTN 


Key Word (table entry and text) 


XIOPST-IEKDIO|Key Word (table entry and text) 


ree ee oe ce ee ee ee cee ee ee ee ce ee ee ee eee ee Ce ce ee ee ee cee eee ee ee ee ee ee I coe ee oe 
fee ce cee Se cee SD cee A ce SE SD cee SE SD eS eS ce NE SS SS ANN nN SED EE cee SED ame SUES semen 
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| Function | 


}Constructs information table entries for| 
{variables and arraysS appearing in COM- 
{|MON, DIMENSION, and EQUIVALENCE state- 
|ments and analyzes these statements for 

| syntactical errors. 

| 
|Develops intermediate text representa- 
{tions of CALL, SUBROUTINE, ENTRY, and 

| FUNCTION statements, constructs informa- 
{tion table entries for the operands of 
{these statements, and analyzes these 
jstatements for syntactical errors. 

| (This subroutine passes control to sub- 
j|routine XARITH-IEKCAR to process the 
Jarguments appearing in CALL statements.) 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 
|Develops intermediate text for NAMELIST | 
jand DEFINE FILE statements, constructs | 
Jinformation table entries for variables | 
Jand arrays appearing in the NAMELIST, | 
{DEFINE FILE, and STRUCTURE statements, | 
jresets the implicit mode table according | 
Jto the specification of the IMPLICIT | 
|statement, and analyzes these statements | 
{for syntactical errors. | 
| 

| 

| 

| 

| 

| 

| 

| 

| 

| 


|Develops intermediate text representa- 
[tions of ASSIGN, RETURN, FORMAT, PAUSE, 
| BACKSPACE, REWIND, END FILE, STOP, and 
{END statements, constructs information 
{table entries for the operands of the 

| ASSIGN, BACKSPACE, REWIND, and END FILE 
|statements, and for the operands (if 
jany) of the RETURN, PAUSE, and STOP 
|statements, and analyzes all of these 
{statements for syntactical errors. 
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e Chart 05. Phase 15 Overall Logic 


RHKEA RGR REE 

* FROM FSD * SEE TABLE 9 FOR A 
* CHART 00 * BRIEF DESCRIPTION 
* * OF THE SUBROUTINES 
OR AOR OEE EEK OF PHASE 15. 


HERRERO E ERK RES 


* TEXT * 
HERE EREKE RE CHEEK 


HERE] JRRERE EKER 
* TO PHASE * 
* 20 VIA FSD * 


HERE REKKKEEKEKE 


Section 2: Discussion of Major Components 81 


e Chart O06. 
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PHAZ15 Overall Logic 
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| 
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| 
| | 
| Vv 
| o®s 07 
F2 *, SOK 4OK FB OK RO tO 
* *. * ALTRAN-IEKJAL * las 
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e Chart O07. ALTRAN-IEKJAL Control Flow 


ALTRAN - IEKJAL 


Primary Function Arithmetic Subscript Relational Logical 
Adjective Code References Operators . Operators Operators Operators 
IEKJDF JEKJAN 
EKJF EKKRE 
ee (IEKKPR)* | (IEKKNO)* 
IEKKPA IEKKSA 
IEKLOK IEKKUN pis te 
(IEKJEX)* JEKLGR 
JEKJBF IEKJCP IEKKSM 
(IEKJMO)* IEKKST 
IEKLGN 


*Secondary entry point of routine immediately above 


NOTE: The logic and flow of the arithmetic translator is too complex to be represented on one or two conventional flowcharts. Chart 07 indicates 
the relationship between the arithmetic translator (subroutine ALTRAN) and its lower-level subroutines. An arrow flowing between two 
subroutines indicates that the subroutine at the origin of the arrow may, in the course of its processing, call the subroutine indicated by 
the arrowhead. In some cases, a subroutine called by ALTRAN may, in turn, call one or more subroutines to assist in the performance of 
its function. The level and sequence of subroutines is indicated by the lines and arrowheads. 


In reality, all of the pathways shown connecting subroutines are two-way; however, to simplify the chart, only forward flow has been 
indicated by the arrowheads. All of the subroutines return control to the subroutine that called them when they complete their processing. 
(If a subroutine detects an error serious enough to warrant the deletion of the compilation, the subroutine passes control to the FSD, rather 
than return control to the subroutine that called it.) 


The specific functions of each of the subroutines associated with the arithmetic translator are given in the subroutine directory following 
the charts for phase 15. 
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eTable 9. 


(6) 


Phase 15 Subroutine Directory 


|address computation, rechains data text, generates adcons for 
|common, equivalence, and external references, sets up error 


|table entries for phase 30. 


(SS Ura rm ae a ee ae ne er Bg rg eg my ey eg ee ee ee 1 
| |Associated} | | 
| Subroutine {Phase 15 | Function | 
| | Segment | | 
See an aa tamara nnn nr nn nnn nnn nnd 
J ALTRAN-IEKJAL | PHAZ15 {Controls the arithmetic translation process. | 
| | (5) | | 
| ANDOR-IEKJAN | PHAZ15 |Checks the mode of the arguments passed to it, decomposes IF | 
PTR NOES | (5) |statements, and generates text entries for AND and OR | 
| | |operations. | 
| | | 
{| BLTNFN-IEKJBF | PHAZ15 |Determines whether or not a given name represents a valid in-| 
| | (5) [line function, and generates phase 15 text for that in-line | 
| | | function. | 
| | | | 
| CNSTCV-IEKKCN | PHAZ15 |Performs compile time conversion of constants. | 
ae 
| CORAL-IEKGCR [| CORAL [Controls the flow of space allocation for variables, | 
| | (6) |constants, and adcons necessary for local variables, common, | 
| | |equivalence, and external references; processes constants, | 
| | {local variables, and external references. | 
| | | | 
|CPLTST-IEKJCP | PHAZ15 |Checks the mode of the operands in an arithmetic triplet mak-| 
| (LEKJMO) | (5) [ing adjustments where necessary and controls text generation | 
| | {for the triplet. | 
| | | | 
| DATOUT-IEKTDT | CORAL |Processes data text. | 
| | (6) | | 
| | | a | 
|DFILE-IEKTDF | CORAL {Processes define file text. | 
| | (6) | | 
| | | —— | 
| DFUNCT-IEKJDF | PHAZ15 |Determines if a reference is to an in-line, library, or ex- | 
| (IEKKPR) * | (5) [ternal function, and determines the validity of arguments to | 
| | [the subprogram; inserts the appropriate function operator | 
| | [into phase 15 text and Luilds the parameter list in the adcon| 
[ | {table and in text for the subprogram referred to; performs | 
| | |parameter list optimization. | 
| | | | 
|DUMP15-IEKLER | PHAZ15 |Records errors detected during PHAZ15 processing. | 
| | (5) | | 
| | | . | | 
| EOVAR- IEKGEV | CORAL {Handles common and equivalence space allocation. | 
| | (6) | | 
| | | . . . | 
|FINISH-IEKJFI | PHAZ15 |Completes the processing required for a statement when its | 
| | (5) [primary adjective code is forced from the pushdown table. | 
| | | | | 
| FUNRDY-IEKJFU | PHAZ15 [Creates pushdown entries for references to implicit library | 
| | (5) | functions. | 
| | | | 
| GENER- LIEKLGN | PHAZ15 {Outputs phase 15 text consisting of unchanged phase 10 text, | 
{ | (5) |phase 15 standard text, and phase 15 statement number text. | 
| | | 
| GENERTN-IEKJGR| PHAZ15 |Builds appropriate phase 15 text entries for simple items | 
| | (5) [forced from the pushdown tabkle. | 
| | | 
| LEKGCZ {| CORAL |Keeps track of space Leing allocated, generates adcons for | 
| | | 
| | 
| | | 

1 J 
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(Continued) 


eTable 9. Phase 15 Subroutine Directory (Continued) 

forte ee ee Bee ee, a a ge ee Oe ee re ey Ie ee a ey seca ee 1 
| | Associated | | 
| Subroutine {Phase 15 | Function | 
| | Segment | | 
}-------------- {--------—- }----~---------------------------------------- =~ ----- === { 
| MATE-TEKLMA | PHAZ15 |Records usage information in the MVS, MVF, and MVX fields if | 
| | (5) lone of the optimized paths through phase 20 is selected. | 
| | | | 
| NDATA-IEKGDA | CORAL |Processes data text. | 
| | (6) | | 
| | | | 
J|NLIST-IEKTNL | CORAL {Processes namelist text. | 
| | (6) | | 
| | | | 
|OP1CHK-IEKKOP | PHAZ15 |Determines if operand 1 should be a temporary and checks for | 
| (LEKKNG) * | (5) Jjnegative arguments. 
| | | | 
| PAREN-LEKKPA | PHAZ15 |Removes the ( or -( from the pushdown table when the corre-_ | 
| | (5) |sponding ) is encountered. | 
| | | | 
J|RELOPS-IEKKRE | PHAZ15 |Calls subroutine GENER-IEKLGN to output text entries for re- | 
| | (5) {lational operators. (Cutput may be either a relational or | 
| | |branch operation.) | 
| | | | 
|STTEST-IEKKST | PHAZ15 |Builds text for replacement statements (e.g., A=B, A=B(I), | 
| : (5) ‘i (I) =B, A(I)=B(I) )- | 
| SUBADD-IEKKSA | PHAZ15 |Generates text to add the terms in a subscript computation; | 
| | (5) |determines if a sukscript text entry in the pushdown takle | 
| | |should be entered into phase 15 text, and calls subroutine | 
| | | GENER-IEKLGN to output the text entry when appropriate. | 
| | | | 
| SUBMLT-IEKKSM | PHAZ15 |Generates the text to multiply the first term of a sukscript | 
| | (5) {computation by its associated length factor, or, in the case | 
| | jof variable dimension, to multiply the nth dimension by | 
| | | length. | 
| | | | 
| TXTLAB-IEKLAB | PHAZ15 |Processes statement number text entries for subroutine | 
| | (5) |GENER-IEKLGN; creates entries in RMAJOR. | 
| | | | 
|TXTREG-IEKLRG | PHAZ15 |Processes standard phase 15 text entries for subroutine | 
| (5) | GENER-IEKLGN and makes RMAJOR entries. | 
| | | | 
|UNARY-IEKRUN | PHAZ15 |Optimizes arithmetic triplets and processes the expcnentia-_ | 
| (ILEKKSW) * | (5) {tion operator. | 
| (LEKJEX) * | | | 
SCR eer aa eee ee Es Wet oN ee a ee eae 
| *Secondary entry points. | 
EES eee an eer ea Te ea PE NT later ce aOR eo ROI ee NPS A DCR EE oO a EE See PENT EASED SOME Te Set a rN at er OR er On eae MR ee J 
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eTable 10. Phase 15 COMMON Areas 
Ca ae ae ee Ge ee a ee og eg eR ge ee ne ee ET a ee og ee eae 1 
PH15-LEKJAT1 Phase 15 common data area. 


CMAJCR-IEKJA2 Backward connection table. 


TEKJA3 Function information takles. 
RMAJOR-IEKJA4 Forward connection table. 
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e Chart 10. 
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e Chart 11. Common Expression Elimination (XPELIM-IEKQXM) 


XPELIM~IEKCXM 
KA RE RR KK 








* FROM * 
* LPSEL-IFKPLS # 
* CHART 10 
REKRKKKEKKKKKKEK 
] 
| 
| 
ee eee ee ee aaa | 
} 1000 v 
We te BR oe a kK ok WARK KAD RK K KKK EK { 
* * * | 
* GET * * GET FIRST # 
* FIRST ene >* TEXT ENTRY IN * | 
* BLOCK + * BLOCK . 
* * * * | 
Ke a aK ek a KK KK Ke KK KKK KK KEK | 
| 
| 
es cae hace ee 
[ V NO 
Shs 9800 sm 
| 5100 C2 *. REEKEKC SHRKKRKEKEKKE Cy x, 
| * = * * o* END *, KKEKCHKRKKKEKKKKE 
_* #. YES + GET NEXT + .* OF *. YES * TO 
*lEND OF BLOCK .#-—---—-->* TEXT BLOCK  *— —>*> CURRENT  .*-—— >* LPSEL-IEKPLS 
1 *. 4 * * *. LOOP .* * CHART 10 
] x, * * * % o* KEKE EK EK KEKE EK 
1 *, J * KKKKKAKERKEHKEEKKKSE *, * 
| * NO * 
! 
| 
| 
| | 
i v 
* 


2000 ~*SFE TABLE 11 21900 
D2 *. 


00 
ReRARD Ah E EE RERERD SORE OR REE 
* * 








* .* 7 * 
GET * NO .* BASIC "*. YES * SCAN FOR + 
r—>*NEXT TEXT ENTRY #<----——~— *] CRITERIA 2*------—-->* LOCAL COMMON * 
* * *, MET .# * “TEXT ENTRY * 
1 * * * .* * * 
{ SK Re Ke OK KK *. * KKK KEK HRA KEKKEKE 
ELT: A * 
* * KKK 
* D1 * Ps * i 
* Ps * FQ eo 
* Kk * * | 
| eK v 
i 4800 v -*. 4000 
| RAED ROR RE E3 *, HRREK RRR RRR EK 
* * .* *, * * 
| * GET FIRST * NO .* *, YES * ELIMINATE * 
* (NEXT) BACK *<--__---*] ENTRY FOUND 2 *---—_-->* EXPRESSION ON *— 
* “DOMINATOR * *, .* * TEXT ENTRY * 
* * x, .® * * 
ee RK ok Fk kok KK KK K *,. .* RE KKKKKKKEKAEKEKE KK y 
| * A RAK 
H * * 
! | ts 
es 
v | 
o*, 3100 I 
F2 *, HH HK YK RK RK Ee ] 
| -* x, * GET * | 
H YES .* END *, NO * FIRST TEXT * | 
tL ———-——————-—-———— * CURRENT LOOP .*———- >* ENTRY IN BACK * { 
ve, -* * “DOMINATOR * 
*, * * * | 
*, .* EKEKMEKEKEEKSEKEREK | 
* 
! | 
| 
[roo | 
V l 
o*, ] 
G3 *, ] 
a * 
NO .* OPERANDS —* | 
—--—*2E3 USED ELSE-.* J 
*,WHERE IN .* } 
*.1C P .* ] 
*, % | 
| 
| 
! 
| YES 
3200 -*SEE TABLE 11 2100 o*. 
* * “a ¥ *, 
7 PRIMARY *. YES e* SECONDARY *. 
+, CRITERIA « *——--—---—-——>*. CRITERIA -* SEE TABLE 11 
*. MET ° *, MET * 
*. .* *, .* 
* NO * NO 
1 
| 
a Te eet EE RE EO 


0 
Per TOME C ELIS LSS SY 
* * 


* GET NEXT TEXT * 
* ENTRY IN BACK * 
7 DOMINATOR * 


* 
REE REKK KK REK EK 


a ce ON ne ND EN gg SRE aS Se ae A ce ch ey SA ema cS SA <n A A os et ee nt ena come SSR eR SEIS snengy crue SO 

| 

| 

| 

| 

| 

t 
Vv 


| 
v 
o *, 
K3 *, 
NO ~* END BACK *. YES 
error pete age DOMINATOR .*——~4 
*, .* | 
*. o* Vv 
* * eK 
* * 
* E2 * 
* * 
RX 


90 


eee 


Am 


e Chart 12. 


BAC 
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e Chart 13. Strength Reduction (REDUCE-IEKQSR) 
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TeTTCTTETL CTCL. T: aoe +. o* 
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e Chart 15. Table Building (FWDPAS-IEKRFP) © 
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e Chart 16. Local Assignment (BKPAS-IEKRBP) 
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Global Assignment (GLOBAS-IEKRGB) 
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e Chart 19. Text Updating (STXTR-IEKRSX) (Continued) 
KREKEK 
¥19 * 
* B3* 
* * 
* 
| 
| 
Vv 
300 ae 
B ss 
.* WHICH *, 
2 .*OPRND BEING*. 3 
i a Sa et ot ee  PROCESSER 4 
| *, .* 
j *, .* 
i eC 
| ne 
| | 
| | 
v v 
o*, 310 *. 
WAS | * .* WAS  *. 
~* OPRND 2° *. YES OPRND 1  *. NO 
*> ASSIGNED BY .*-—— #2 ASSIGNED BY o 82s 
. BKPAS .* } . EKPAS .* 1 
x, o* *, * 
MS og ® *o | 
* NO $OK HK * YES | 
*18 * | 
* FQ* | 
* * ] | 
* | j 
v v | 
o*. 285 i 
D1 x, eK TD ee KK KK KKK B3 x, j 
oe FS: He * x USE * .* MUST *, | 
-* OPRND = *. YES * SAME REG. AS * -*OPRND 1 BE *. NO { 
*. OPRND 1 0F  .*-------~>*OF1 OF PREVIOUS* *: STORED ena i 
*, PREVIOUS .* * TEXT ENTRY * i ; 7 i- 
*, ENTRY. * * * *. .* | { 
x, UK FO RR OR ROR a RO fete ok ok *, o® v | 
* NO * RE EKK 
: 3 : — | 
| | * F2* 
| | — | 
| v | v 
\ Sei 10330 oy 10350 .*. 
| ee? eee ae ee aan w 
| YES .* = * SET STATUS * YES .* OPRND 71 °*. 
(ese Sere eae? REG. U * * TO GENERATE *<—— —-*, BE STORED .* 
-. . + STORE * +. - 
me, Uk wTTTrTTrTTTi TTT rT a 
| * ° NO ' *” NO 
KKK K | ! 
eae \ | | 
* F1 *> | | 
nee ae e509 \ 
Les F2 .*, 10370 v 
325 Fl x, F3 *. KERR ERY RAKE KEKE 
-* IS ‘ o* IS *, * * 
7 BASF . YES -* OPERAND *. NO *- SET STATUS  #* 
*> REGISTER OK .*-——, *. A TEMPORARY Saran =. 28S PREVENT * 
ie, .* oe * j x. : * 
eo e ¥ Vv *. * | EKKKKEKKKAKEKEKEKSE 
* NO KKK * YES | t 
+ P28 | 
ts | eeuxe 
v | *1Q * 
.*. v i * FQ* 
10325 G1 xe KR HR GD RK KK HK REKAKG SHREK KEKE x * 
se TS. #, * RECOR-IEKRRL * * * * 
~*  OPEND . YES kK RK HK * ALLOCATE * 
*. A TEMEORARY .*---__-___>* FREF STORAGE * * STORAGE FOR * i 
. .* _* FOR TEMPORARY * * TEMPORARY * | 
*. .* * IF POSSIBLE * * * | 
*, * RR RR Ke eK KKK aK KK KKK KK KKK KEK KKK KK 
* NC | j | 
[- 
eo y 
V j 
Fcc i a pean Sata eat S| 
36 v 
D cugediereesiuaws 
* * 
* FIND BASF * 
* REG. FOR * 
‘ OPERAND : 


98 


MRR ROR RR KR RR RE KK 


ewe ames a0 ner ems 


KERR I ERARE EERE 
* RECCRD * 
* BASE INFO. * 
* FOR * 
* APPROPRIATE * 
* OPERAND * 
KRERAKEKRE RR EEK EK 
| 


v 
REKEKK 
*18 * 
* FR* 

x * 


* 


So ena mae 


C5 *. 
-* WAS *, 
YES .* OPRND 3 *. 
r——*. ASSIGNED BY .* 
° BKPAS -* 
ee 
KKKKK * NO 
*14 * 
* P2* 1 
x *& 
‘ | 
y 
os 
D5 *, 
-* IS *. 
NO .* OPRND # *, 
*,. OPRND 1 OF o * 
{ *, PREVIOUS . 
| * ENTRY. * 
Vv *. .* 
eX KK * YES 
* * 
* FT * 
* * 
REKK | 


REECE RSH ECE KRREEE 
* USE * 
* SAME REG. AS * 
*OP1 OF PREVIOUS* 
. TEXT ENTRY * 


* 
EKER HK EK EEK 





v 
90330 *. 
F5 *. 
* *, 
NO » 
rna* REG. 0 * 
*, .* 
v *, .* 
1 * YES 
* * 
* FY * 
* * v 
er He to 
*18 * 
* P2* 
* * 
x 


eTable 11. Criteria for Text Optimization 


fra ee Oe are Se re er er og ee RS a a ee er Me a ert ee ee 1 
| Process | Basic [ Primary | Secondary | 
| ----~-------------}----------------------}---------------------- ---------------------- 

| Common |Subscript, arithmetic Lone peeeeeniernes 2 {Matching operand 2, | 
| Expression Jor logical operator; |operand 3, and | Joperand 3, and | 
| Elimination [binary operator |operator Joperator with | 
| | | Jno intervening | 
| | jredefinitions | 
|------------------ {~--------------------- ------~-~-------------}-------—-------------- { 
| Backward JArithmetic or logical |Operand 2 and {|Operand 1 not busy | 
| Movement |operator {operand 3 undefined Jon exit from target; | 
| | [in the loop Joperand 1 undefined | 
| | | {elsewhere in the loor | 
|-----~------------ }~-------------------—- {---------—---------—- }~---------------------- { 
| Strength |Additive operator; {Interaction of inert |Function of absolute | 
| Reduction |anert variable |variakle with additive|constants or stored | 
| | Jor multiplicative |constants | 
| | {operator | | 
Bs ete he ee ee Mi Soden tit ieee oe ia Onn ee itise ee oe eRe ena eee eee ae a es 4 
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eTable 12. Phase 20 Subroutine Directory 


SS ees Sa ee ee ee Po ey 
‘Sabroutine | Function | Type | 
Se ca ac he IN es Sr Na oh a a eee oe as ee oe et 4————--__---.—- 
| BACMOV-IEKOBM|Controls backward movement, produces new inert text [Text 
lentries for strength reduction, Ltuilds type tables for |optimization 
|strength reduction, and performs compile-time mode | 
{|conversions. | 
| | 
BAKT-IEKPB [Computes the loop number of each module block. |Structural 
| | determination 
BIZX-IEKPZ |Computes the proper MVX setting for each variable in each |Structural 
[block of the module. | determination 
| 
BKDMP-LEKRBK |Printing routine for full register assignment. |Register 
| | assignment 
| 
BKPAS-IEKRBP |Control local register assignirent. {Register 
| |assignment 
| | 
BLS-IEKSBS |Computes the total size of each Llock in the module and {Branching 
|determines which module biocks can be reached via RX branch|optimization 
[instructions. | 
| 
CXIMAG-IEKRCI|Processes imaginary parts of complex functions during |Register 
[local register assignment. |assignment 
[ 
FCLT50-IEKRFL|Performs special checks on text items whose function codes | 
jJare less than 50. | 
| 
FOLLOW-IEKQF |Determines if intervening -lock causes redefinition of a [Structural 


|variable. | determination 


FREE-IEKRFR |Releases busy registers during overflow conditions (local |Register 


| 

| 
| | 
| | 
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| | 
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| | 
| | 
| | 
| | 
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| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | | | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| L | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 
| | 


{assignment) . | assignment 
FWDPAS-IEKRFP|Table-building routine for full register assignment. |Register 
| | assignment 


FWDPS1- LEKRF1|Determines if text operands are register candidates prior {Register 


{to local register assignment. |assignment 
| 
GLOBAS-IEKRGB|Assigns most active variables to registers across the {Register 
| loop. | assignment 
| | 
INVERT-IEKPIV|Gets text pointers in a backward direction. | Text 
| joptimization 
| | 
LOC-IEKRL1 {Biock data for register assignment. | 
| 
LPSEL-IEKPLS |Controls sequencing of loops and passes control to text {Control 
Joptimization and register assignment routines | routine 
| | 
REDUCE-IEKQSR|Controls strength reduction. jText 
| Joptimization 
| 
REGAS-IEKRRG |Controls full register assignment. [Register 
| |assignment 


ELCOR-IEKRRL|Releases temporary main storage so it can be reused. 


SEED Sa GC TREATS 


R 
SEARCH-IEKRS |Provides register loads upon entering the module. 
S 


PLRA-IEKRSL |Assigns registers during basic register assignment. [Register 
| | assignment 
eae eee Ae ee a Sas sa a a de oe oa te J 
(Continued) 
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eTable 12. Phase 20 Subroutine Directory (Continued) 


Ge ok ee ge ee Re an ee tase ge qt Se ee 1 
| Subroutine | Function | Type | 
PRN EEN NEE Se OT IN! NDE Ae eM ree TIN ee eee RT CRAY ieee AE Ste epee ee AR Aen Jen eee A ee Ee a he 
|SSTAT-IEKRSS |Sets status information for operands and kase addresses | Text | 
| jof text entries. joptimization | 
| | 
| STXTR-ILEKRSX |Controls text updating. |Register | 
| | {assignment | 
| | | | 
|TARGET-IEKPT |Identifies the members of a loop and its back target. | Text | 
| | Joptimization | 
| | | | 
| TOPO-ITEKPO |Computes the immediate back dominator of each block in the |Structural | 
| |module. | determination | 
| « | | | 
|TNSFM-IEKRTF |Performs special checks on text items whose function codes | | 
| Jare in the range of 50 to 55 inclusive. | | 
| | | | 
| TYPLOC-ILEKQTL|Locates interactions of text entries for strength | Text | 
| |reduction. Joptimization | 
| | | 
| XPELIM-IEKOXM|Controls common expression elimination. [Text | 
| | joptimization | 
a ee a aed at i Na ag aa ee Sk oe eT in ees ea i) Ke Sip PET RAO, J 
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eTable 13. Phase 20 Utility Subroutines 


Ge age Or pag ee ye E Me ge ee Oe WER oe tae ETI Ne Be Oog ot ee eC TF Pee Ge an Ee a ea wo IN 1 
| Subroutine | | Function | 


| CIRCLE-IEKOCL | : | 
| (FOLLOW-IEKQF) * |Examines composit vectors, or each local vector if necessary. 


| CLASIF-IEKQCF {Classifies operands of the current text entry, changes parameter list 
(PARFIX-IEKQPX) *|to correspond to text replacements, adjusts text entry for possible 
(MODFIX-IEKQOMF) *|mode change. 


| 

| 

| GETDIK-ITEKPGK [Fills text space according to the arguments, gets space for tem- 
| (FILTEX-IEKPFT) *|poraries, gets space for constants, obtains previous text entry. 
| (GETDIC-IEKPGC) * | 

| (INVERT-IEKPIV) * | 

| 

| 

| 

| 


KORAN-IEKQKO {Performs bit manipulation for text optimization, updates composit LMVS 
(LORAN-IEKQLO) * |and LMVF matrixies. 

| (DELTEX-IEKQDT) *|updates MVS and MVF vectors. 

| SaRnOR- aEORE ee combination of constants at compile time. 

| SRPRIZ-IEKQAA Pennies source program listing routine. 

| Saneuaeoes Hieoiaees operands with equivalent values and, if possible, operand 

| Jvalues with equivalent values. 

Gan annont ieeaeee trace printing routine for text optimization. 

eee {Performs local block scan for backward movement, for common expression 


| (YSCAN-IEKQYS) * |elimination, and for forward movement. 
| (ZSCAN-IEKQZS) * | 
}~--------------- Nn nnn nnn nn nn nnn nnn { 


|(*Secondary entry point | | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| MOVTEX-ITEKOMT {Moves text entries, deletes current text entry ny rechaining, and | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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Chart 20. Phase 25 Processing 
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1 *. a* *, o* * BLES * 
! x, * *. . * EKKKKEKKKKEKEKEKK 
| 1 YES | * NO 
eae ere a 
| | en EE a | 
| 
| vy 
j V KEKE KC PKK EKEKEKHK 
j HRC RIO CF * * 
| * TO FSD * * GET FIRST * 
* CHART 01 * * (NEXT) TEXT * 
i * * * ENTRY * 
WK he OK aK Kak K * * 
| $B OK SO a Oe 
j 


D2 we, HARK D SRK EK EE EEE 
RETU URN *. * TENTKT-LEKVIN * 
* Ly END, *. YES *~%—8—*— 4% 8 Ft 
«2 STMT. Sell DETM ENT TYPE #<——f——--—- 
*, NO. .* *PRODUCE LBL MAP* 
| *, .* *IF END OF TEXT * 
*, .* SRKEKKSRKKKKEREKEKE 
| *” NO 
| eK 
ee. 
| | L_>* Bp. * 
x * 
i v EK 
o*¥e 
| E2 ¥*. AKEEKE IRE E SER ES 
| .* * * FNCALI-IERVFN * 
i .* *. YES He ke 
| * CALL See tans GENERATE. * 
i s é * CALLING * 
j *, Ee *  SECUENCE * 
} *. ' REKKKEKREKKKKREKEKK 
REKK 
| os ‘ 
>* BT * 
j | * * 
| y RHEKX 
oe *e 
| EKKKKP TERK EKRKE F2 *. KEKE YREKEKEREKE 
| * * .* *, * SUBGEN-IEKVSU * 
| * SET UP * NO .* 1/0 *. YES a ae ae ae ee ee oo 
| * REGISTER py oeemmnenreets 2 LIST Te -_____>* GENERATE py ae ene >* 
* ARRRAY * *, ITEM .* * TEXT FOR LIST * 
j * * *, .* * ITEM * 
| RK HK KK KO EEK K KK *., .* REKKEKRKEEKHKKKKEK 
x 
REKK 
} ] * * 
j i_>* B1 * 
* * 
| ] Pes S 3 
v 
HER KG TREKS 
] * * 
i & SELECT * 
j * BIT * 
* STRIP * 
* * 
| HOR KKK KE Oe KKK KKH 
| 
{ 
| 
| 
| ROR RORY PK RK KK KE KK 
{ *« * 
| * MODIFY STRIP * 
* FOR BASF * 
| * LOADS AND * 
* STORES * 
} Tee Se TC eT STS Ts 
] 
| 
| | 
V 
ToL EREC SCS SS ts Ts 
: * * PERFORMED BY APPROPRIATE 
HK HR RR CODE GENERATION SUBROUTINE 
| * GENERATE aes 
* INSTRUCTIONS * | 
* FROM SKELETON * | 
RHR EKER KKEKKEKRSEEK 
KKKK 
* * 
* Bi * 
* * 
1 xKaEKS 
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: 
| 
: 
| 
| 
i 
| 
! 
| 
| 
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: 
| 
| 
| 
| 
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Section 2: 


———>SUBROUTINE 
MAINGN-IEKTA 
CONTRCLS TEXT 
CONVERSI 


SRKKERSKKEKREKKEK 


* RETURN-IEKTEN * 
1 H— — FF 


<——->* GENERATE * 
* BRANCH TO * 
* EPILOGUE * 


KEKE EEE KEKE KEK 


! 
| 
| EERE CS EEE EE RER EE 
* IOSUB-IEKTIS * 
KK RH KH KK 
| <> sGENERATE BRANCH * 
* TO IHCFCOMH * 
* * 
| 


REKKKKEKKE KKK KS 


KEKKKHS EKKEKEREKE 


pi PABEL TERTUB * 
K— F— K— *K 





___-_______-->]<__->* "ENTER Loc. 

* CTR. IN + 

* LABEL ENTRY * 

EKEEKKKKEKEKREKKEK 

21A2 

ERKKK EHR EKRKEKEKES 

| * END-LTEKUEN * 

X— K— K— K— K— KH K— * 

<——>* COMPLETE * 

I * PROCESSING * 

| * OF MODULE #* 

REKKKEKKKREKKEKEKE 

AEREEP RRR EEK OR ERE PS EEE KEKE EE 

* IOSUB-IEKTIS * | *ITEKGMP * 

K— ¥— *— K— F— K~ K— F— K { K— K— K— K— KE K— HK KH 
GENERATE <t PRODUCE an 

* CALL TO * STORAGE * 

* THCPCOMH : * MAP * 


ER EK KEKE EKKKEKKE REKEKKKKEKEKEEEKKE 
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e Chart 21. Subroutine END-IEKUEN 

















ao *, 
RRERE A DEKE EE EEE REREAD SRERESSEREE AY *. 
AEREA [ERE ERE RED * ENTRY-IEKTEN * * PROLOG-IEKTPR * * *, 
* FROM * t— #— K— RK FR ¥— Fk 4 ~~ KH 2ND 
* MAINGN-IEKTA 5 DETERRING TYPE *<-————-——>* GENERATE $a 8, ENTRY POPPED gfe hake 
* CHART 20 * CF PROLOGUE ¥* A * FROLOGUE * *. 
KeSTERCERETERSE *EPILOGUE TO GEN* | * * *, 
Terr rer rerre eel S| | HERE E REE ERR EE *, . 
| | tio | 
| 
| | | 
| \ : _ ; | 
| 
y | 
REHAB DRE EERE S | AHEKER SERRE AEKKE 
* OUTPUT ADCONS * | * BRL ECCILENSEE * 
* FCR PROLOGUE, * { Stee eta ee Fe * 
* SAVE AREA, -* GENERATE. 1 
vi EPILOGUE : : EPILOGUE : 
EKER EERE REE PHRERED EAE TEER ES 
| 
| 
V 
Ld * 2 
C2 *. HEREC IRAE EKEEE 
‘“ *, * * 
-* ANY *. YES * OUTPUT ADCONS * 
*. BRANCH « *¥————-————>* FCR PRANCH * 
*., TABLES .*# - TABLES * 
* .* * * 
*, Ft EKER AER ERERER 
* NO | 
| 
! 
Oa eae aes en ee J 
V 
s * es 
D2 *, HERSEK EERE HEED 
.* * * * 
-* ANY *. YES * OUTPUT ADCONS * 
*. PARAMETER silanes aaa a FOR PARAMETER : 
*. LISTS .* LISTS 
x .* + * 
a a RARER AEREE EE EEE EE 
* NO 
| | 
| | 
hanes tl ci a tae ei 
V 
s * * 
E2 *, KEKE E ZEEE EERE EK 
.* * * * 
* OUTPUT * 
*.ANY P20 TEMP... *---—— >*ADCONS FOR B20 * 
- ° * TEME. * 
*, .* * * 
*. Jt HRERRARERE EE ER ERE 
* NO | 
| | 
| 
Poe see ey 
V 
~*. 
F2 *. REP SR EE a 
.* * * * 
° * OUTPUT * 
* "R* BLOCK .*--—— >*ADCONS FOR *B* * 
*. LABELS .* * BLOCK LABELS * 
*. .* * * 
| HEERERREEKEEAKK ER 
* NO 
oe eae 


y 
KEKE G DEREK EE EEE 
# 


* CQUTPUT END 
* CARD FOR OBJ. 
* MODULE 


HHH HH 


* 
HERRERA KR KKK EK KKK 


<j eat ee: 


KEKE DEKERKEKEEE 


TO 

* MAINGN-IEKTA 
* CHART 20 
RKREEEKEEREK EEE 


% 3% 


104 


e Table 14. 


Si ae ee el 


ADMDGN-IEKVAD" 
BITNFP-IEKVFP' 


BRLGL-IEKVBL? 


CGNDTA-IEKWCN 
END-LEKUEN 


ENTRY-IEKTEN 


EPILCG-I&#KTEP 


FAZ25-ITEKP25 


FNCALL-IEKVFN 


GOTOKK-ITEKWKK 


TOSUB-IEKTIS/ 
TOSUB2-IEKTIO 


LABEL-IEKTLB 


LISTER-LIEKTLS 


MAINGN-LEKTA/ 


MAINGN2-IEKVM2 


PACKER-IEKTPK 


PLSGEN-LIEKVPL" 


PROLOG-IEKTPR 
RETURN-LEKTRN 
STOPPR-IEKTSR1 


SUBGEN-IEKVSU" 


Phase 25 Subroutine Directory 


eee See SE ERED eee ED ED en ED Ee ee eee ate ee une TE NE ES ER ES EES AE EEE TED REND RTE SS SD SSN ARS DO EE RD LE RRS SR SS EE ARO EY SS END SRE ELLE SO A GSES “SEED SD SOUP eS SEED SD GREED GENS SEND ES UE REND SEED SE CTD SSS ED EE SUE ARMED ERD ERD SEER SEES SD NDS ORD OR OD 


Generates instructions for the AMOD, DMOD, ABS, 
COMPL, LCOMPL, and DBLE in-line functions. 


IABS, DABS, AND, OR, 


Generates instructions for the following text entries: BITCN, 
BITOFF, BITFLP, TBIT, MOD24, SHFTR, and SHFTL in-line functions. 


Generates instructions for the following text entries: operator is 
a relational operator operating upon two operands or upon one 
operand and zero, assigned GC TC operators, computed GO TO opera- 
tors, unconditional branching, branch true and branch false opera- 
tions, and ASSIGN statement. 


Initializes the arrays used during code generation. 
Performs final processing of the object mcdule. 
Calls routines PROLOG-IEKTPR and EPILOG-IEKTEP to generate prologues 


and epilogues for subroutines and secondary entry points. Generates 
prologues and epilogues for the main program. 


Generates the epilogues associated with a subprogram and its secon- 
dary entry points (if any). 


Common data area used by phase 25. 


Generates calling sequences for CALLs (other than those to IHCFCOMH) 
and function references. Generates the instructions to store the 
result returned by a function Subprogram. 


Used by MAINGN-IEKTA to branch to the code generation subroutines. 


Generate calling sequences for calls to IHCFCOMH. 


Processes statement numbers Ly entering the current value of the 
location counter into the statement number entry in the dictionary. 


Produces a listing of the final compiler-generated instructions. 


Assign base and displacement for ‘'B" block labels and branch takle 
entries. Control the text conversion process of phase 25. 


Packs the various parts of each instruction produced during code 
generation into a TXT record. 


Generates the instructions for the following text entries: real 
multiplication and division operations, subtraction operations, 
half- and full-word integer multiplication, and half- and full-word 
integer division. 

Generates prologues for subroutines and secondary entry points (if 
any) - 


Processes the RETURN statement Ly generating a branch to the 
epilogue. 


Generates character strings in calls to IHCFCOMH for STOP and PAUSE 
statements. 


Generates instructions for the following text entries: subscript 
operations, right and left shift operations, store operations, and 
list item operations. 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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| 
| 
| 
| 
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| 
J 
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eTable 14. Phase 25 Subroutine Directory (Continued) 


sie ade hahaa aac 
| 


A A EES SUED TET ANE RE ES cE ED YD AI RD EES SD ae 


TENTXT-LEKVTN 


TSTSET-IEKVTS" 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| UNRGEN-IEKVUN' 
| 

| 

| 

| 


ITEKGMP 
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— 4 


Function 


Controls the processing of END, RETURN, and I/O statements, state- 
ment numpers, and end of I/C list indicators. Produces label map. 


Generates the instructions to (1) compare two operands across a 
relational operator, and (2) set operand 1 to either true or false 
depending upon tne outcome of the comparison. Generates the follow- 
ing in-line functions: FLOAT, DFLOAT, INT, IDINT, IFIX, HFIX, DIM, 
IDIM, SIGN, ISIGN, DSIGN, MAX2, and MIN2. 


Generates the instructions for tne fcllowing text entries: unary 
minus operations (e.g., A=-B), logical NOT operations, load byte 
operations, load address operations, AND, OR, and XOR operations. 


Produces a storage mar. 


Ae Le OD ON AS A A lS ER GD NE RS SD ED SS SSE SS EE NS SS SE “EUS SEN GE GREED SS ED SOI GD SD SOS “GNI AGES “EEL SERENE ONS << SALTS EE ID TD SERA GEIS SON ERS SEED SOR AGED PEND OD IN NE SS “ES ED SRN ARTES ED ON SUE “NI: ARI SONI a cine 


ae aE a pe ee ee Ree eT a eT Page PE OOS ae Le eS Ye ee A ae ee a are er ea ee ae 1 


—-—-—-—-—~—-——-- ————-—-—- —- — -- --—- - - + - + | 


en 


e Chart 22. Phase 30 (IEKP30) 
TEKE30 
RK A HK KKK SFE TABLE 45 
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* CHART 01 * FACH SUBROUTINE 
DK oR XE eK a eK KK OF PHASE 30. 
| 
| 
| 
| 
| 
| 
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SOR RB J eR ROKK 
te 


of 
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* INITIALIZF * 
* * 
* * 
HR ROR RK RH KK KK 


l 
| 
| 
| 


Pert Ss eee re ere ss) 
*OBRTAIN MAXIMUM * 
+ ENTEIES AND * 
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POR ORR ROR RR ROKK 


Overali Logic 


D3 *. TET TSC Tee TT es tT. 
~* ACTUAL *¥. * SET UP ERROR * 
~»*NO. GREATER*. YES * MESSAGE * 
*, THAN THAT .*-~—~———-—~——>* AND rn en 
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*. _* x « | 
xk oe TTT TTT CTT TT TT Tr | 
*" NO 
% HK | | 
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# ES *>] i 
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Kok tOK | | 
LDERCOM 
errs eer TTT et ts eT | 
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* (NEXT) ERRCR * | 
* TABLE ENTEY * 
* * 
TeTTETITTTLECT Te | 
| fet | 
| ‘oe 
| * FD #>| 
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v HOR 
Pa STRESS1 OFFSET 
F3 * FOR IOK F Lp a aR aK OR ROR FS RK KK 
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~ * NUMBER *., NO * ADDRESS * — K— KKK K— K— KK K 
*.,L/T 1000 AND .*-----—-—-- >* FOR ERROR Hi a ae ae me > WRITE * 
*, G/T 0 -* * MESSAGE * * ERROR * 
*, o* * * * MESSAGE * 
*. werrrrrrrTrTtrit tT: TTT TT TTT TT TTT TT 
Y | 


| 
V 
ERR G RRR ERK KH 
* OBTAIN * 
* ERROR LEVEL * 
* CCDE FRCH #* 
* GRAVERR * 
* TABLE * 
WR HOR RR HO OK 
| 
i 
| 
v 
Pe art 
H3 x, RE RRR GK KK 
-* ERROR *, * SAVE * 
-*LEVEL CODE *. YES * ERROR * 
*.G/T ERFVIOUS . *-—-—-——>* LEVEL * 
*, ONES  .* * CODE * 
*, .* * * 
x, O* KOK ROK ROR ROR ROR ROR ROK 
+ NO | 
| | 
] | 
| { 
| <--+-+-+———-—-- 4 
| 
HASH V 
WR RHR 4 KK KK 
* GET * 
* ASSOCIATED * 
* MESSAGE * 
* POINTFR TAELF * 
* ENTRY * 
PELE SESE CLE SCL SS 2 2 


ars ee sees 


REE K DRE RK KK 

* * 

* BUILD * 

* PARAMETER *——— 

* ‘List { 

* * | 

HR ORR SOR OR mK ok V 
tO 
* * 
* FSH * 
* x 
RK 


| 
! 
| 
| 
Vv 
a*s 
CS. Fs 
2* LAST *, 


NO .* ERROR *, 
r-—-*. TABLE * 
| *, ENTRY .* 
| x, .* 

Vv *, .* 
KKK * YES 
* x | 
* £3 * | 
* * J 
HK | 

| 
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ROK RORY Ste a a 
* PASS SAVED * 
* ERROR * 
* LEVEL * 
* CODE * 
* * 
ROR ORR KR kK a OR ROK 
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Table 15. Phase 30 Subroutine Directory 


foo re eT fae ee eg eT gaa ep Oe a yr gee eg eee ep re eT re eT ee INI Se ee ye 1 
| Subroutine | Function | 
Se ee la Se ea aS a a | 
| ITEKP30 | Controis phase 30 processing. | 
| | | 
| MSGWRT- | Writes the error messages using the FSD. | 
| ITEKP31 | 
eet a eae ee are Ree I Na a a aa Ra ce re J 
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This appendix contains text and figures 
that describe and illustrate the major 
tables used and/or generated by the FCRTRAN 
System Director and the compiler phases. 
The tables are discussed in the order in 
which they are generated or first used. In 
addition, table modifications resulting 
from the compilation process are explained, 
where appropriate, after the initial for- 
mats of the tables have been explained. 


\ 


COMMUNICATION TABLE (NPTR) 


The communication table (referred to as 
the NPTR table in the program listing), as 
a portion of the FORTRAN System Director, 
resides in main storage throughout the com- 
pilation. It is a central gathering area 
used to communicate necesSary information 
among the various phases of the compiler. 


Various fields in the communication 
table are examined by the phases of the 
compiler. The status of these fields 
determines: 


e Options specified by the source 
programmer. 


e Specific action to be taken by a phase. 


If the field in question is null, the 
option has not been specified or the action 
is not to be taken. If the field is not 
null, the option has been specified or the 
action is to be taken. Table 16 illus- 
trates the organization of the communica- 
tion table. 


CLASSIFICATION TABLES 


Classifying, a function of the prepara- 
tory subroutine (GETCD-IEKCGC) of phase 10, 
involves the assignment of a code to each 
type of source statement. This code indi- 
cates to the DSPTCH-IEKCDP subroutine which 
Subroutine (either keyword or arithmetic) 
is to continue the processing of that 
source statement. The following paragraph 
describes the processing that occurs during 
classifying. The tables used in the clas- 
Sifying process are the keyword pointer 
table and the keyword table. They are 
illustrated in Tables 17 and 18, 
respectively. 


If the source statement has not been 
Signaled as arithmetic during source state- 
ment packing (See note), the classifying 
process determines the type of the source 


eTable 16. 


APPENDIX A: TABLES 


Statement ky comparing the first character 
of the packed source statement with each 
character in the keyword pointer table. If 
that first character corresponds to the 
initial character of any keyword, the key- 
word pointer table is then used to cktain a 
pointer to a location in the keyword table. 
This location is the first entry in the 
keyword table for the group of keywords 
beginning with the matched character. All 
characters of the source statement, up to 
the first delimiter, are then compared with 
that group of keywords. If a match 
results, the classification code associated 
with the matched entry is asSigned to the 
source statement. If a match does not 
result, or if the first character of the 
source statement does not correspond to the 
first character of any of the keywords, the 
source statement is classified as an inval- 
id statement. 


Note: The packing process, which precedes 
classifying, marks a source statement as 
arithmetic if, in that statement, an equal 
Sign that is not bounded by parentheses is 
encountered. If the source statement has 
been marked as arithmetic, it is classified 
accordingly by the classification process. 


Communication Table (NPTR (2,35) ) 
Pao eines Soe es Cees Sr 1 
| 1]/Pointer to tempo- |Pointer to 1-char- | 
|  |rary for FLOAT/FIX|acter symbol chain | 
|--+------------------ {—----~------------- { 
2|Previous classifi-|Pointer to 2-char- 
|cation code (phase|acter symbol chain 
|10) ; Reg used on | 


| | 
| | 
| | 
| |last ARITH (phase | | 
| |20,OPT=0) | | 
|--+------------------ 4--------~---------- { 
| 3|/Cptions: SCURCE, |Pointer to 3-char- | 
| |MAP, ID, EDIT, |acter symbol chain | 
| |LOAD, DECK, LIST, | | 
| |BCD, XREF | | 
}-—}---_—---------—-— +--—---------------- { 
| 4{Pointer to most {Pointer to 4-char- | 
| {recently generated|acter symbol chain | 
| |EQUIVALENCE group | | 
|  |entry (phase 10); | | 
| |Relative location | | 
|  |of first temporary] | 
| (phase 20) | | 
|--+------------------ +--~---------------- { 
| S|NADCON index for |Pointer to 5-char- | 
| |first temporary [acter symbol chain | 
| | (phase 20) | 
}--4------------~---~-4------------------- { 
| 6|Maximum line count{|Pointer to 6-char- | 
| | Jacter symbol chain | 
BB Bae a re Pe ee SNe ee J 


(Continued) 
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Communication Table (NPTR (2,35)) 


(Continued) 
ay - - - - - - - - - - yp ee 
7 | NADCON index for pointer to last | 
jlast statement j|dictionary entry | 
{in stmt number | 
| 


eTable 16. 


| number 

| {chain (XREF-phase 

| |10) ; Number of reg-| 

| Jisters reserved for| 

| |RX branches (phases| 

| {20 and 25) | 
|--}------------------ $------------------- { 
| 8|Type of text | | 
| | (phase 10) ;Pointer | | 
| |to next phase 10 | | 
{| |text item (phase | | 
{ |15); Pointer to | | 
| |-QXX temporary | | 
|  |chain (phase 20) | | 
|--}------------------ 4------------------- { 


| 9| Pointer to next |Pointer to last | 
| |available phase 10]available phase 10 | 
| |text entry jtext entry | 


110] Name of routine | 
| | (subprogram/main program) | 
|--4}------------------}------------------- 3 
{11|Phase in control |Trace switch; opt- | 
{|  |indicator Jimization downgrade| 
; | | switch | 
}--4------------------ }------------------- { 
{12|Last error table | | 
| [entry | | 
|--4+----------~-------}--—-----—___------ { 
{13{END card indicator|Pointer to first | 
| | (phase 10) |card of source pgm | 
}--+------------------}-----------------—- : 

|14| Pointer to |Pointer to 4-byte _ | 
| |parameters {constant chain | 
bee the ek et ee a ee ee 

{15|NADCON index for |Pointer to 8-byte | 
| |first parameter |constant chain | 
| [list | 
a 4{——_____-_____ 

|16| Page count |Pointer to 16-byte | 
i | Jconstant chain { 
|--+------------------+------------------- { 


{17|Current line count|]Pointer to state- | 
Jment number chain | 
|18|Relative location |Number of branch ; 
|  |for register 13 jtable entries; rel-| 
| | Jative location of | 
; | Jregister 12 | 
|--+~----------------- +------------------- { 
|19|Active register: |NADCON index for | 
|  |zero for reg 13, |statement number | 
| |nonzero for Reg 12|adcons | 
ON ae Sees een ter sapere pee RN Meee ee J 


(Continued) 


eTable 16. Communication Table (NPTR (2,35) ) 
(Continued) 

BD en ee ee 1 
| 20 Seconda? entry ‘inamber of times | 
| |points if nonzero |XREF buffer has | 
| | [been written out | 
{ | | (phase 10) l 
|--+-~----------------+------------------- | 
}21|Location counter |NADCCN index for | 
{| | [first CCMMON area _ | 
}--4------------------}------------------- 
}22]Pointer to dic- |Next available | 
|} |tionary entry for |Jerror table entry | 
} |IBCOM | 
}--+~----------------- {—----~-~----------- 
]}23|External function |Pointer to end of | 
} and/or CALL ind- |statement number | 
| |aicator | chain | 
eee ee | 
}24|Program uses [Optimization level | 
| |FLOAT/FIX or MOD | | 
|  |function if non- | | 
| |zero; arithmetic | | 
|  Jinterrupt indica- | | 
| [tor | | 
~-+------------------ 4-------------------1 
}25|Pointer to first |Pointer to common | 
|  |dicticnary entry {|chain | 
SU hos a a ree ee | 
}26]Pointer to DEFINE |Pointer to equiva- | 
| |FILE text [lence chain 
}27|Pointer to literal|Pointer to data | 
} |constant chain [text chain © | 
Bee ee ee teed 
}28|Pointer to DIOCS |Pointer to normal | 
| |jentry {text chain | 
DR ee epee eS nae pre ee eT Sera ee rast ee | 
|29|Pointer to branch |Pointer to next | 
|} |table chain [available informa- | 
|} | {tion table entry | 
a aig a elo eee ceca | 


]}30|BLOCK DATA sub- [Pointer to end of | 
|  |program switch [information table | 
|31|FUNCTION SUB- | SUBROUTINE SUB- | 
| |PROGRAM switch | PROGRAM switch | 
——4——-__-__~____-___ +} _ +--+ 
]}32|Pointer to name- |Pointer to format | 
| |jilist text chain Jtext chain } 


{33|]Size of constants |Size of variakles | 

Paar (penetra a ote ny aan een er et yee Wegner a eieigee rene Siren mea meer mn | 

}34|Current displace- |Adcon entry number | 
[ment from active | 
|register (phase | 
| 20) | 

]}35|Relative location 

| |for first state- 

j {ment number 


Delete/error switch] 


pe ome aoe a 
be — — — 


rf 
| 
| 
be 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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e Table 17. 


SO EE ES A NS CD NS TS AN SS A A A A A A ANS SS eR A A A A A A SL AAA SC A A A A SS EL a ee A EN SOS me 


T 
Character | Number' 
(1 byte) {| (1 byte) 

sk Se ene nee eae or 4---—~—-~----~ 

A | 2 
| 

B | 2 
| 

C | 5 
| 

D | 8 
| 

E | 5 
| 

F | 3 
| 

G | 1 
| 

H | 0 
| 

I { 3 
| 

J | 0 
| 

K . | 0 
| 

L | 2 
| 

M | 1 
| 

N | 2 
| 

0 | 0 
| 

P |“ 3 
| 

Q | 0 
| 

R | 5 
| 

S | 3 
| 

T | 2 
| 

U | 0 
| 

V | 0 
| 

W | 1 
| 

X | 0 
| 

x | 0 
| 

Z | 0 


-}— —— — — — — — 


Keyword Pointer Table 


ae a cores eRe eee em eee oes cme ee cums comes ee eee as eee ee cee ee ee cee ee ee ee eR A DD ED AD EY CR EY AOR Re 


Displacement? 
(2 bytes) 
12 
34 
84 
175 
220 


244 


250 


286 


312 


318 


336 


357 


399 


428 


{*This field contains the number of key 
words beginning with the associated 


character. 


from the beginning of the key word table 
for the group of key words associated 


with character. 


| 
| 
{2This field contains the displacement | 
| 
| 
| 


eTakle 18. Keyword Table 

alee ae eee eee Spe ee ee ee ee 
| Length-1"* | Key Word? |Code? | 
}---------- {~---------------------- +-~---- { 
| 5 | ASSIGN | 1 | 
| | | | 
| 1 [AT | 9 | 
| | | | 
| 8 | BACKSPACE | 2 | 
| | | | 
| 8 | BLOCKDATA l 3 | 
| | | | 
| 7 | CONTINUE | 5 | 
| | | | 
| 5 | COMMON | 7 | 
| | | | 
| 3 {| CALL | 8 | 
| | | | 
| 14 | COMPLEXFUNCTION | yh | 
| | | | 
| 6 | COMPLEX | 6 {| 
| | | | 
| 8 | DIMENSION | 14 | 
| | | | 
| 3 | DATA | 17 | 
| | | | 
| 22 | DOUBLEPRECISIONFUNCTION| 10 | 
| | | | 
| 14 | DOUBLEPRECISION | 11 | 
| | | | 
| 1 | DO {| 18 | 
| | | 
| 9 | DEFINEFILE | 13 | 
| | | | 
| 6 | DISPLAY | 15 | 
| | | 
| 4 | DEBUG | 16 | 
| | | | 
| 10 | EQUIVALENCE {| 19 | 
| | | | 
| 6 | ENDFILE {| 21 | 
| | | | 
| 3 [END (group mark) * {| 23 | 
| | | | 
| 4 | ENTRY {| 22 | 
| | | | 
| 7 | EXTERNAL | 20 | 
| | | | 
| 5 | FORMAT | 25 | 
| | | | 
| 7 | FUNCTION {| 24 | 
| | | | 
| 3 | FIND | 12 | 
| | | | 
| 3 | GOTO {| 27 | 
| | | | 
| 7 | IMPLICIT | 29 | 
| | | | 
| 14 | INTEGERFUNCTION | 28 | 
| | | 
| 6 | INTEGER | 30 | 
| | | 
| 14 | LOGICALFUNCTION | 33 | 
|---—---——--~— te ate et he fcc | 
| *Represented in hex as ‘C5D5C44F* | 
a ee ms ae Si er as ns J 

(Continued) 
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eTable 18. ee Table (Continued) 


Ge a te a ee 2 aa hie 1 
| Length- 11] Key Word? | Code | 
[---~-—---- $----------------------- +------ { 
| 6 | LOGICAL } 35 | 
| | | | 
| 3 | MOVE ; 34 | 
| | | | 
| 7 | NAMELIST | 36 | 
| | | 
| 5 | NORMAL | 37 | 
| | | | 
| 4 | PAUSE | 38 | 
| | | | 
| 4 | PRINT }; 39 | 
| | | 
| 4 | PUNCH j 40 | 
| | | 
| 3 | READ | 44 | 
| | | | 
| 5 | RETURN | 43 | 
| | | | 
| 5 | REWIND | 42 | 
| | | | 
| 11 | REALFUNCTION ; 41° | 
| | | | 
3 | REAL ; 45 | 
| | | | 
| 3 | STOP {| 48 | 
| | | | 
| 9 | SUBROUTINE | 46 | 
| | | | 
{ 8 | STRUCTURE | 47 | 
| | | | 
| 7 | TRACEOFF {| 49 | 
| | | | 
| 6 | TRACEON | 50 | 
| | | | 
| 4 | WRITE | 51 | 
bet See Se she ee eee | 
|*This part of the entry for each keyword | 
| 1S one byte in length and contains a | 
| value equal to the number of characters | 
| in that keyword minus one. | 
-|2This part of the entry for each keyword | 
} contains an image of that keyword at one| 
| byte per character. | 
|?This part of the entry for each keyword | 
{| is one byte in length and contains the | 
| classification code for that keyword. [ 
ae ete a et Ne We See ear tee eee clam ea ea eT TEES! 4 


NADCON TABLE 

The NADCON table, built by PHAZ15 and 
CORAL and partially overwritten by phase 
20, contains: 


1. Parameter list pointers. 


2. Adcons for locai variables and 
constants. 


3.  Adcons for variables in COMMON and for 
those equivalenced into COMMON. 


4. Adcons for external references. 


eTakle 19. 


The information in the table is used by 
CORAL and phase 25. Each table entry is 
one word in length; the format of the table 
is shown in Table 19. 


NADCON Takle 

eat Ree eta et ee 1 
paraneter list pointer entries (one word | 
[per entry) | 


|Adcon entries for local variables and i 
[constants (one word per entry) { 
|Adcon entries for variables in CCMMON and| 
Jthose equivalenced into COMMON (one word | 
[per entry) [ 
t 


|Adcon entries for external references ] 
| (one word per entry) | 


Parameter entries are created by PHAZ15. 
Fach entry iS a pointer to the dictionary 
entry for the parameter. Indicators denote 
ends of parameter lists and also parameters 
shared by more than one function or subrou- 
tine call. 


Adcon entries are created Ly CCRAL and 
then inserted by CORAL into the adcon por- 
tion of the object module as shown in 
Figure 9. Pointers to temporaries are 
created by phase 20 and placed in the por- 
tion of the table used previously by CORAL. 


Phase 25 inserts the parameters and tem- 
poraries into the object module. The 
right-hand portion of Figure 9 indicates 
the order in which storage is assigned in 
the object module and the data which is 
entered into that storage. 


INFORMATION TABLE 


The information table (referred to as 
NDICT or NDICTX) is constructed Ly Phase 10 
and modified by subsequent phases. This 
table contains entries that describe the 
operands of the source module. The infor- 
mation table consists of five components: 
dictionary, statement number/array table, 
common table, literal table, and branch 
takle. 


INFORMATION TABLE CHAINS 


The information table is arranged as a 
number of chains. A chain is a group of 
related entries, each of which contains a 
pointer to another entry in the group. 
Each chain is associated with a component 
of the information table. 


The information table can contain the 
following chains: 


e A maximum of nine dictionary chains: 
one for each allowable FORTRAN variable 
length (1 through 6 characters) and one 
for each allowable FORTRAN constant 
Size (4, 8, or 16 bytes). Each dic- 
tionary chain for variables contains 
entries that describe variables of the 
Same length. Each dictionary chain for 
constants contains entries that 
describe constants of the same size. 


e One statement number/array chain for 
entries that describe statement 
numbers. 


e Two common table chains: one for 
entries describing common blocks and 
their associated variables, and one for 
entries describing equivalence groups 
and their associated variables. 


e One literal table chain for entries 
that describe literal constants used as 
arguments in CALL statements. 


e One branch table chain composed of 
entries for statement numbers appearing 
in computed GO TO statements. 


Entries describing the various operands 
of the source module are developed by Phase 
10 and placed into the information table in 
the order in which the operands are encoun- 
tered during the processing of the source 
module. For this reason, a particular 
chain's entries may be scattered throughout 
the information table and entries descrik- 
ing different types of operands may occupy 
contiguous locations within the information 
table. Figure 10 illustrates this concept. 


CHAIN CONSTRUCTION 


The construction of a chain requires (1) 
initialization of the chain, and (2) point- 
er manipulation. Chain initialization is a 
two step process: 









1. The first entry of a particular tyre 
(e.g., an entry describing a variable 
of length one) is placed into the 
information table at the next avail- 
able location. 


2. A pointer to this first entry is 
placed into the communication table 
entry (refer to the section, “Communi- 
cation Table") reserved for the chain 
of which this first entry is a member. 


Subsequent entries are linked into the 
chain via pointer manipulation, as 
described in the following paragraphs. 


The communication table entry containing 
the pointer to the initial entry in the 
chain is examined and the first entry in 
the chain is oktained. The item that is to 
be entered is compared to the initial 
entry. If the two are equal, the item is 
not reentered; if unequal, the first entry 
in the chain is checked to see if it is 
also the last. (An entry is the last ina 
chain if its “chain" field is zero.) 


If the chain entry under consideration 
is the last in the chain, the new item is 
entered into the information takle at the 
next available location, and a pointer to 
its location is placed into the chain field 
of the last chain entry. The new entry is 
thereby linked into the chain and becomes 
its last mwember. 


If the entry under consideration is not 
the last in the chain, the next entry is 
obtained ky using its chain field. The 
item to be entered is compared to the entry 
that was obtained. If the two are equal, 
the item is not reentered: if unequal, the 
entry under consideration is checked to see 
if it is the last in the chain; etc. 


This process is continued until a com- 
parable entry is found or the end of the 
chain is found. If a comparable entry is 





Ce a rs ye ag ee rae ey a ee ee ge 1 
| | 
| | 
aos 
Ss Sf. L\ SS 
| pS a te ee 4-- 4-4, | 
| | | | | | STMT | | STMT | | | | | 
| | DICT | COMM | BRAN| DICT | ARRAY | LIT | ARRAY | COMM|LIT|BRAN|DICT | | 
| | 1 | to | t | 2 ft 1 | 2 [2 [| 2] 2 | 3 | | 
| og = | 
| 7 | 
| / | 
| | 
| | 
| | 
Fa a a a ag ah a ar a ce J 
Figure 10. Information Table Chains 
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If the 
it is 


found, the item is not reentered. 
new item is not found in the chain, 
then linked into the chain. 


OPERATION OF INFORMATION TABLE CHAINS 


The following paragraphs describe the 
operation of the various chains in the 
information table. 


Dictionary Chain Operation 


The operation of a dictionary chain is 
based upon “balanced tree" notation. This 
notation provides two chains, high and low 
(with a common mid-point), for the entries 
describing variables of the same length or 
constants of the same Size. The initial 
mid-point is the first entry placed into 
the information table for a variable of a 
particular length or a constant of a parti- 
cular size. When two entries have been 
made on the high side of the mid-point, the 
first entry on the current mid-point's high 
chain becomes the new mid-point. Similar- 
ly, when two entries have been made on the 
low side of the mid-point, the first entry 
on the current mid-point's low chain becom- 
es the new mid-point. 


A change of mid-point for a variable of 
a particular length or a constant of a par- 
ticular size causes a pointer to the new 
mid-point to be recorded in the communica- 
tion table. The following example illus- 
trates the manner in which phase 10 employs 
the balanced tree notation to construct a 
dictionary chain. 


Assume that the following variables 
appear in the source module in the order 
presented. 


D C E F A B 


When phase 10 encounters the variable D, 
it constructs a dictionary entry for it 
(refer to “Dictionary") , places this entry 
at the next available location in the 
information table, and records a pointer to 
that entry into the appropriate field of 
the communication table (refer to “Communi- 
cation Table"). The entry for D is the 
initial mid-point for the chain of entries 
describing variables of length one. (When 
a dictionary entry is placed into the 
information table, both the high and low 
chain fields of that entry are zero.) 


When phase 10 encounters the variable C, 
it constructs a dictionary entry for it. 
Phase 10 then obtains the dictionary entry 
that is the initial mid-point and compares 
C to the variable in that entry. If the 
two are unequal, phase 10 determines if the 
variable to be entered is greater than or 
less than the variable in the obtained 
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entry. In this case, C is less than D in 
the collating sequence, and, therefore, 
phase 10 examines the low chain field of 
the oktained entry, which is that for D. 
This field is zero, and the end of the 
chain has been reached. Phase 10 places 
the entry for C into the next available 
location in the information table and 
records a pointer to that entry in the low 
chain field of the dictionary entry for D. 
The entry for C is recrene linked into the 
chain. 


When the variable E is encountered, 
phase 10 carries out essentially the same 
procedure; however, because E is greater 
than D, phase 10 examines the high chain 
field of the entry for D. It is zero, 
which denotes the end of the chain. Phase 
10 therefore places the dictionary entry 
for E into the next available location in 
the information table and records a pointer 
to that entry in the high chain field of 
the dictionary entry for D. 


When the variable F is encountered, 
phase 10 constructs a dictionary entry for 
it and compares it to the variable in the 
entry that is the initial mid-point for 
the chain. Because F is greater than D, 
phase 10 examines the high chain field of 
the entry for D. This field is not zero 
and, hence, the end of the chain has not 
yet been reached. Phase 10 obtains the 
entry (for E) at the location pointed to by 
the nonzero chain field (of the entry for 
D) and compares F to the variable in the 
obtained entry. The variable F is greater 
than the variable E. Therefore, phase 10 
examines the high chain field of the entry 
for Ew. This field is zero and the end of 
the chain has been reached. Phase 10 
places the entry for F into the next avail- 
able location in the information table and 
records a pointer to that entry in the high 
chain field of the entry for E. Since two 
entries have now been made on the high side 
of the current mid-point, the first vari- 
able on D's high chain becomes the new 
mid-foint. 


Phase 10 carries out similar procedures 
to link the entries for the variables A and 
B into the chain. 


(If one of the comparisons made between 
a variable to be entered into the dic- 
tionary and a variable in an entry already 
in the dictionary results in a match, the 
variable has previously been entered and is 
not reentered.) 


Figure 11 illustrates the manner in 
which the entries for the variables are 
chained after the entry for B has been 
linked into the chain. : 


7 
| | 

| 

~~—__—” ws | 
a : 

[1st and 2nd | 
{3rd mid- mid-point | 
{points | 
| | 
! | 


|Note: High and low chains are maintained] 
|\for all entries. when the entry for F is| 
Jmade, the mid-point shifts from D to E. | 
{When the entry for A is made, the mid- | 
{point shifts from E to D. | 
Gece es eh te ee i ee 4 


Figure 11. Dictionary Chain 


Statement Number Chain Operation 


The statement number chain constructed 
by phase 10 is linear; that is, each state- 
ment number entry (refer to “Statement 
Number/Array Table") is pointed to by the 
chain field of the previously constructed 
Statement number entry. The first state- 
ment number entry isS pointed to by a point- 
er in the communication table. 


To construct the statement number chain, 
phase 10 places’ the statement number entry 
constructed for the first statement number 
in the module into the next available loca- 
tion in the information table. It records 
a pointer to that entry in the appropriate 
field of the communication table. (When a 
statement number entry is placed into the 
information table, its chain field is 
zero.) Phase 10 links all other statement 
number entries into the chain by scanning 
the previously constructed statement number 
entries (in the order in which they are 
chained) until the last entry is found. 

The last entry is denoted by a zero chain 
field. Phase 10 then places the new entry 
at the next available location in the 
information table and records a pointer to 
that entry in the zero chain field of the 
last entry in the chain. The new entry is 
thereby linked into the chain and becomes 
its last member. (Throughout the construc- 
tion of the statement number chain, phase 
10 makes comparisons to insure that a sta- 
tement number is only entered once.) 


Common Chain Operation 


The chain constructed by phase 10 for 
the common information appearing in the 
source module is bi-linear; that is, phase 
10 links together: 


1. The individual common block name 
entries (refer to “Common Table") that 
it develops for the common block names 
appearing in the module. 


2. The dictionary entries (refer to “Dic- 
tionary") that it develops for the 
variables appearing in a particular 
common block. (The dictionary entry 
for the first variable appearing ina 
common block is also pointed to by the 
common Ltlock name entry for the common 
block containing the variable.) 


To construct the common chain, phase 10 
places the common block name entry that it 
constructs for the first common block name 
appearing in the module at the next avail- 
able location in the information table. It 
records a pointer to this entry in the 
appropriate field of the communication 
takle. Phase 10 then obtains the first 
variable in the common block, constructs a 
dictionary entry for it, places the entry 
at the next available location in the 
information table, and records a fointer to 
that entry in the P1 and P2 field of the 
common block name entry for the common 
block containing the variable. Phase 10 
obtains the next variakle in the common 
block, constructs a dictionary entry for 
it, places the entry in the information 
table, records a pointer to that entry in 
the common chain field of the dictionary 
entry constructed for the variable encoun- 
tered immediately prior to the variable 
under consideration, (this entry location 
is obtained from the P2 field of the common 
block name entry), and records a pointer to 
the information table for the new common 
variable in the P2 field. Thus, the P2 
field of the common block name entry always 
contains a pointer to the information takle 
entry for the last variable of a given com- 
mon block. Phase 10 obtains the next vari- 
akle in the common block, etc. 


When phase 10 encounters a second unique 
common block name, it constructs a common 
block name entry for it, places the entry 
in the information table, and records a 
pointer to that entry in the chain field of 
the last common block name entry, which is 
found by scanning the chain of such entries 
until a zero chain field is detected. 

Phase 10 then links the dictionary entries 
that it constructs for the variables 
appearing in the second common block into 
the chain in the previously described 
manner. 


If a common block name is repeated in 
the source module a number of times, phase 
10 constructs a common block name entry 
only for the first appearance. However, it 
does include as members of the common Llock 
the variables associated with the second 
and subsequent mentions of the common Llock 
name. Phase 10 constructs a dictionary 
entry for the first variable associated 
with the second mention of the common Elock 
name and places it into the information 
takle. It then records a pointer to the 
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dictionary entry for the new variable in 
the common chain field of the last variable 
associated with the first mention of the 
common block name. Phase 10 links the dic- 
tionary entry it constructs for the second 
variable associated with the second mention 
of a common block name to the dictionary 
entry for the first variable associated 
with the second mention of that name; etc. 


If a third mention of a particular com- 
mon block name iS encountered, phase 10 
processes the associated variables ina 
Similar manner. It links the dictionary 
entries constructed for these variables as 
extensions to the dictionary entries devel- 
oped for the variables associated with the 
second mention of the common block name. 


Equivalence Chain Operation 


The chain constructed by phase 10 for 
the equivalence information appearing in 
the source module is also bi-linear. Phase 
10 links together: 


1. The individual equivalence group 
entries (refer to “Common Table") 
it constructs for the equivalence 
groups appearing in the module. 


that 


2. The equivalence variable entries 
(cefer to “Common Table") that it con- 
structs for the variables appearing in 
a particular equivalence group. (The 
equivalence variable entry for the 
first variable appearing in an equiva- 
lence group is pointed to by the 
equivalence group entry for the group 
containing the variable.) 


The construction of the equivalence 
chain by phase 10 parallels its construc- 
tion of the common chain. It links the 
equivalence group entries in the same man- 
ner aS it does common block name entries, 
and links equivalence variable entries in 
the same manner as the dictionary entries 
for the variables in a common block. (The 
location of the last EQUIVALENCE group 
entry generated is recorded in the appro- 
priate field of the communication table; 
the location of the last EQUIVALENCE vari- 
able entry generated is recorded locally in 
the keyword subroutine which processes the 
EQUIVALENCE statement). 


Literal Constant Chain Operation 


The chain constructed by phase 10 for 
the literal constant information appearing 
in the source module is linear. The liter- 
al constants are chained in reverse order 
of occurrence. Phase 10 records a pointer 
to the most recent literal constant entry 
generated. As each new entry is made it is 
chained to the previous entry and it in 
turn is recorded as the most recent. 
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Branch Takle Chain Operation 


The phase 10 construction of the branch 


‘table chain parallels that of the statement 


number chain. It records a pointer to the 
first branch table entry (refer to "Branch 
Table") it places into the information 
table-in the appropriate field of the con- 
munication table. For each other branch 
table entry, phase 10 records a pointer to 
its location in the information takle in 
the chain field of the previously developed 
branch table entry. Unlike statement num- 
ber entry processing, no lakel comparison 
is necessary. Scanning the chain is there- 
fore avoided by recording the location of 
the last branch table entry in the P2 field 
of the first Initial Branch Table entry. 


INFORMATION TABLE COMPONENTS 


The following text describes the con- 
tents of each component of the information 
takle and presents figures illustrating the 
phase 10 formats of the entries of each 
components. Modifications made to these 
entries Ly subsequent phases of the compil- 
er are also illustrated in figure form. 


Dictionary 


The dictionary contains entries that 
describe the variables and constants of the 
source module. The information gathered 
for each variable or constant is derived 
from an analysis of the context in which 
the variable or constant is used in the 
source module. 


VARIABLE ENTRY FORMAT: The format of the 

dictionary entries constructed by phase 10 
for the variables of the source module is 

illustrated in Figure 12. 


High Chain Field: The high chain field is 
used to maintain linkage between the 
various entries in the chain. It contains 
either a pointer to an entry that collates 
higher in the collating sequence or an 
indicator (zero), which indicates that 
entries in the chain that collate higher 
than itself have not yet been encountered. 


Byte A Usage Field: This field is con- 
tained in the first byte of the second 


word. This field indicates a portion of 
the characteristics of the variable for 
which the dictionaty entry was created. 

The byte A usage is divided into eight sub- 
fields, each of which is one bit long. The 
bits are numbered from 0 through 7. Figure 
13 indicates the function of each subfield 
in the byte A usage field. 


@ Figure 13. 


pr ee Ree er tee ae 7 
| {High chain field { 
aE: {oS Sa ee 
{Byte A |Byte B | 
jusage field|]usage field|DIS field | 
}----------- +~-----------1----------------- { 
| {Low chain field | 
|----------- 4——————--~-~ ~~--------------- { 
|Mode field IType field | 
|---------— 1------—---- 1-----~~-------~-- { 
|Used by | | 
| STALL- | | 
| LEKGST |P1 field | 
}----------- 4-----~----------------------— { 
|Not used | 
|-------—---  SUEEESSEIED anu EEN { 
|SF field {Common chain field | 
}----------- 4-~---—~~~---~~---~~---------- { 
| Name field | 
|~--------------~------—------------------ { 
| Name field | 
Se rae A ee re aN Re a ah Nh Re CN le Re J 
Figure 12. Format of Dictionary Entry for 
Variable 
(ora ee 5 Ra aa 1 
| Subfield | Function | 
|---------~-- {——-----------~-------------- { 
{| Bit 0 ‘on' | variable is structured | 
|------—--—-- {----_-----—~~~-=----—------~ { 
{| Bit 1 ‘on" | symbol referred to | 
}---~---—---- }---------------------------- { 
| Bit 2 ‘on | variable is in common | 
|------------ }---------------------------- { 
{| Bit 3 ‘on' | not used | 
|------------ }---------------------------- { 
| Bit 4 ‘on' | variable is equated | 
|—--------~~ {---~-—-------—------------- { 
{| Bit 5 'on" | variable has appeared in an} 
| | equivalence group that has | 
| | been processed by STALL- | 
| | IEKGST (used by phase 15) | 
}~----------- }---------------------------- { 
| Bit 6 "on" | variable is an external | 
| | function name | 
}------------ }---------------------------- { 
|} Bit 7 ‘on* | not used | 
eae ees ee ee Se ae pen eee ane eee tre Od ee ee Nee eR Sate ER 4 


Function of Each Subfield in 
the Byte A Usage Field of a 
Dictionary Entry for a Variable 
or Constant 


Byte B Usage Field: The byte B usage field 
is contained in the second byte of the 
second word. This field indicates addi- 
tional characteristics of the variable 
entered into the dictionary. It is divided 
into eight subfields, each of which is one 
bit long. The bits are numbered from 0 
through 7. Figure 14 illustrates the func- 
tion of each subfield in the byte B usage 
field. 


e Figure 14. 


ee ee mee ee ee ae ge eS 1 
| Subfield | Function | 
|------------ }-------------~-------------- 
| Bit 0 fon" | variable is "call by value"|]| 
| | parameter | 
}------------ {~--------------------------- 
| Bit 1 ‘on' | variable is "call by name" | 
| | parameter | 
}------------ }---------------------------- { 
| Bit 2 ‘on* | variable is used as an | 
| | argument | 
|------------ {--—--~------------------—-- { 
| Bit 3 ‘on'" | not used | 
}------------ }---------------~------------ { 
| Bit 4 ‘on* | variable has appeared ina | 
| | previous DATA statement | 
| | (phase 15) | 
}~---—------- }~-~--~-—-----—-------------- { 
|} Bit 5 ‘on' | variable is used as a | 
| | subscrift | 
|~----~---~-- }---------------------------- { 
| Bit 6 "on" | variable is in common, or | 
| | in an equivalence group and| 
| | has been assigned a rela- | 
| | tive address (phase 15) | 
}------------ }~---~----------------------- 
| Bit 7 ‘on* | variable appears in DATA | 
| | statement | 
ES sae ean Lee sea ae yf aneengelchare Serres MY Ree oe aE y POD OS nee eee Nes sence aN J 


Function of Each Subfield in 
the Byte B Usage Field of a 
Dictionary Entry for a Variakle 


DIS Field: The DIS field contains either 
the displacement of a structured variable 
from the head of its structure group or the 
number of dummy arguments for a statement 
function name. If the variable is neither 
structured nor a statement function name, 
this field contains a count of the number 
of times the variable appears in the source 
program. 


Low Chain Field: The low chain field is 
used to maintain linkage between the 
various entries in the chain. It contains 
either a pointer to an entry that collates 
lower in the collating Sequence or an indi- 
cator (zero), which indicates that entries 
in the chain that collate lower than itself 
have not yet been encountered. 


Mode/Type Field: The mode/type field is 
divided into two subfields, each two bytes 
long. The first two bytes (mode subfield) 
are used to indicate the mode of the vari- 
able (e.g., integer, real); the second two 
bytes (type subfield) are used to indicate 
the type of the variable (e.g., array, 
external function). Both the mode and type 
are numeric quantities and corresfond to 
the values stated in the mode and type 
tables (see Tables 20 and 21). 


P1 Field: The P1 field contains either a 
pointer to the dimension information in the 
statement number/array table if the entry 
is for an array (i.e., a dimensioned vari- 
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able), or a pointer to the text generated 
for the statement function (SF) if the 
entry is for an SF name. If the entry is 
neither for the name of an array nor the 
name of a statement function, the field is 
Zero. 


Table 2U. Operand Modes 


eS oo ae ee ee T 
| Mode of Operand 


}--—— a eee cr ete ee en a RS ee SS cee SO eee ee ee ee ee 


Logical*1 
Logical *4 
Integer*¥z2 


| 
| 
| 
+ 
| 
| 
| 
Integer | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
and 


Internal 
Representation 
(in hexadecimal) 


a ee eS A HE ES ES SD se SEE EE ee ET eee eee eee ee 


ReEaL*s 

Real*4 
Complex*16 
Complex*8 
Literal 
Statement number 
iexadecinial 
Namelist 

Repeat constant 


ee en eee ere ee eee eee eae une eam ame Tem iene enn aoe ED A ED SE SERED 


(ee ee wee oe ee 
ba er een eS SE eee cee SE cere enema memes meen commen ames odious ancien cone nme 


Table 21. Operand Types 


ee ee T 
Type of Operand 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
ad 


Internal 
Representation 
(in hexadeciral) 


| 
| 
| 
+ 
{Scalar | 
{Dummy scalar | 
{Array | 
{Dummy array | 
{External function | 
| Constant { 
{Statement function | 
|Negative scalar | 
|Negative dummy scalar] 
|Negative array | 
|Negative dummy array | 
|Negative external [ 
| tunction | 
|Negative constant | 
|Negative statement | 
{function 
{OXX temporary | 
| (created by text | 
a eee | 

4 


| Ny el Pe Uae et ey CP a rl Pac rele am 


Cyt we Ooo Ci No es 


mo 


wee mn er ence cre es ete me en cme ee eee eee men ame Senne come comme meena comes media arene ccm ammeme 


A A ND A: SS RE SD a ee ee SD ED SEED eee <eoeem 


SF Field: The SF field contains STORE- 
FETCH inforniation for the variakle. If the 
variable is stored into, bit 0= 1; if the 
Variable if fetched, bit 1=1. 


Common Chain Field: This field is used to 
maintain linkages between the variables in 
a common block. It contains a pointer to 
the dictionary entry for the next variable 
in the common block. (If the variable for 
which a dictionary entry is constructed is 
not in common, this field is not used.) 
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Figure 15. 


Name Field: This field contains the name 
of the variable (right-justified) for which 
the dictionary entry was created. 


MODIFICATIONS TO DICTICNARY ENTRIES FOR 
VARIABLES: During compilation, certain 
fields of the dictionary entries for 
variables may be modified. The following 
examples illustrate the formats of dic- 
tionary entries for variables at various 


| stages of phase 10 and phase 15 processing. 


Only changes are indicated; * stands for 


unchanged. 


Dictionary Entry for Variable After Pre- 


paration for XREF Processing: The format 
of a dictionary entry for a variable after 


CSORN-IEKCCR procesSing is illustrated 
Figure 15. 


poe ee = pea SS Se Se 1 
| | * | 
-}---------- +—-—--——— SS RE | 
| * | * * 
p----------+-------- 1 - --- -- -- | 
| [= | 
poS=S-=S-5- fae Sasa ree elas po a a atid | 
| * | * | 
}---------- ~e =e = 41-—--—-—-—-———— — - = { 
| + * | 
posHsSeaes= Lea ee { 
| * | 
p= SSeS Sse= ict ck cc ta ama { 
| ¥ | * | 
Seek eset eae 5 eee eee ere eee ee eee ere 


|XREF buffer pointer-|* | 
[last entry | | 


|XREF buffer count | XREF buffer rointer-| 
| {first entry 
A ch ies ee ee a ee a J 
Format of Dictionary Entry for 
Variable After CSCRN-IEKCCR 
Processing for XREF 


XREF Buffer Pointer - Last Entry: This 
field contains a pointer to the rost recent 


XREF buffer entry for the symbol. 


XREF Buffer Count: This field ccntains a 
count of the number of times the XREF buff- 
er has been written out on SYSUT2 at the 
time the time this dictionary SDEEy is 
modified ky CSCRN-IEKCCR. 


AREY Butter Pointer —-Farst- Entry: This 
field contains a pointer to the first XREF 
buffer entry for this symbol. 


Dictionary Entry for Variable After Dic- 
tionary Rechaining: The format cf a dic- 
tionary entry for a variable after the dic- 
tionary has been rechained during STALL- 
IEKGST is illustrated in Figure 16. 


<4 bytes +» 4 F' bytes —______, 


(ar ee ai Tee ee ee eee ee ge 1 (SS Sea SN aa ala em a 71 
| | New chain field | | | New chain field | 
|----------}~---------y------------------- {| }---------- }---------- q------------------- 
| * | * | * | | * | * [Displacerent from | 
}—---—----—--— 4+——---—---—-- i-————————~—~—~—~~—--~—~—~ 4 | | [start of common | 
| kg | | | | block | 
}---------- 4——--——---~~ t------------------- {| }---------- }---------- 4——--—~-~----~~----- { 
| + * | | | * | 
|---------- p---------- 4------------------- {| ----------- 4----------7------------------- 
| * * | | * * | 
}---------- 4 --~—- ~~ =~ - 3 ~-- === ~~ === =~ {| }----------1---------- 4 ---—-—-~--~~~~---~- { 
| + | | * si | 
|----------------------------------------- {| }----------4------------------------------ 
| * ek | 
Fann A aeiaeae cee aE ack Rois cae fo | p---+--==---=--=—- === === +--+ +--+ --- { 
| * | | * | 
}~--------------------~------------------- {| }--------------------~--------------------- 
| * | Ie | 
Ra oe OD a ao ee TaN Poe a nn Ree av Ne ee a pe ee 4 ba eee ee ee ee eae | 
e Figure 16. Format of Dictionary Entry for | * | 
Variable After Rechaining b_—————————~— ~~~ ~—~—~—-——~————-————~—-—-——--——-—---—-—- 4 


eFigure 18. Format of Pictionary Entry for 
Variabie After Conrron Rlock 


Dictionary entry for Variable After Coor- Processing 
dinate Assignment: The format of a dic- 
tionary entry for a variable after coordin- $$$ _—__—__—_- 4 bytes ———_________""_» 
ate assignment by STALL-IEKGST is illus- .-~--------- y---- nn 1 
trated in Figure 17. | | New chain field | 
}--~------- $---------- q-~----------------- { 
SSE Dy es Se Se | * | * [Displacement from | 
f--- on - y----- 1 | | {start of common | 
| hig | | | | |olock | 
[---------- $--------—- Porn {| }---------- $--~------- 4-—---~----~=--~---~- { 
| * | * | * | | {Pointer to entry containing | 
---——~--—-—--—+4--—-----—~--- 41———~—~——~~—~—~—~——~—-~—~—~—~—- 4 | {crointer to address ccnstant | 
| | * | | |for variable | 
|--~------- 1-— ~~~ ~~~ 7--~----=~---------— {| }---------- 1————-~——-—~ prin anon 
| * | * | Le ie | 
[---------- prose Bann {| }---------~7---------- 4————----—---------- { 
|Coordinate|* | es - | 
{number for| | }———-——-——--— 4————~—~—~-~—~—~—~—~—~~—~—~~~———~—--—-—~—- { 
[variable | | | * | 
}---------- 1--—--~ ~~~ -—~----------------- {| | }----------------------------------------- { 
| * | | * | 
|----------------------------------------- {| }------------~----------~-------~--------- { 
| + | i | 
| -----~----------------------------------- {| f----------~----------+----------------—- { 
lo | = | 
a ee ee es | en ere ee pe Pa Na aI OD OD ne ee 4 
| * {| e@Figure 19. Format of Dictionary Entry for 
L_——__—__—_—~—~~—~~—~—~~~~~——~~—~-———~—-———-~--—------- 4 a Variable After Relative 
@ Figure 17. Format of Dictionary Entry for Address Assignment 
Variable After Coordinate 
Assignment 


CONSTANT ENTRY FORMAT: The format of the 


er ts rt a  -c 


dictionary entries constructed by phase 10 


Dictionary Entry for Variable After Common for the constants of the source module is 
Block Processing: The format of a dic- illustrated in Figure 20. 
tionary entry for a variable after common 
block processing is illustrated in Figure The format of a dictionary entry fora 
18. constant is the same as for a variable. 
Tne changes the entry undergoes during pro- 
| Dictionary Entry for Variable After Rela- cessing are the same except that bytes 3 
| tive Address Assignment: The format of a and 4 of word two contain a displacement 
| dictionary entry for a variable after rela- from an associated address constant and a 
| tive address assignment is illustrated in constant does not undergo XREF processing. 
| Figure 19. Also, for constants referred to implicitly, 
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PHAZ15 sets a referenced bit on. (pit 1 in 
byte A usage field), see Figure 13. 


——— 4 bytes —————————@9rwr 


Gar 5 a a a a a a 1 
| | Chain field | 
paae reer SSs fae Sesser SS Siig eile ale SRRAaCaR OT { 
{Byte A {Byte B |Used by phase 15 | 
[Usage fField|Usage field| | 
}----------- }----------- 4-—---------------- { 
| | | 
fori era a5 signed SC Ge ee ee eS ie { 
| Mode field [Type field | 
|----------- y----------- 4_~---—--—-~----—- ! 
{Used by | Zero | 
| STALL- | | 
| LEKGST | | 
|----------- 4-----~~-----~---------------- { 
| Constant field | 
|-------------------~-~--~--------~--------- { 
| Constant field | 
| ----------~-----------+------------------- { 
| Constant field | 
|------~--~------------------------------- { 
{ Constant field | 
Be ace ae a ea ae ea ee J 
Figure 20. Format of Dictionary Entry for 
Constant 


Statement Number/Array Table 


The statement number/ array table con- 
tains statement number entries, wnich 
describe the statement numbers of the 
source module, and dimension entries, which 
describe the arrays of the source module. 


STATEMENT NUMBER ENTRY FORMAT: The format 


of the statement number entries constructed 


by phase 10 is illustrated in Figure 21. 


4 bytes ——————___““89 


Poe ores Br eee re rp ee a ae 7 
| | Chain Field | 
}----~--- +----~--- .---------- ¥------------ { 
| Byte A | Byte B | Used by | Used by | 
| Usage | Usage | phase 20 | phase 20 
|-------- t-------- 4-—-—-~—--— A_-——-—--~-—~ { 
{ | Pointer field | 
|-------- Ne { 
| image field | 
|-----------------~--~--------------------- { 
| | 
| ----------------------------------------- { 
| Used by phase 15 | 
|~---------------------------------------- { 
| Used by phase 15 | 
Na a eee se ee ee ne See J 
Figure 21. Format of a Statement Number 


Entry 


Chain Field: The chain field is used to 
maintain linkage between the various 
entries in the chain. It contains either a 
pointer to the next statement number entry 
in the chain or an indicator (zero), which 
indicates the end of the statement number 
chain. 
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| ciated with the statement number. 


Byte A Usage Field: This field is con- 
tained in the first byte of the second 


word. This field indicates a portion of 
the characteristics of the statement number 
for which the entry was created. The byte 
A usage field is divided into eight sub- 
fields, each of which is one bit long. The 
bits are numbered from 0 through 7. Figure 
22 indicates the function of each subfield 
Of this field. 


Gre re ee ea aS eS 1 
| Sukfield { Function | 
|~----~------ }~-----------~---------------- 
| Bit 0 ton" | statement number defined | 
}-------~---- |--~---~--------------------- 
| Bit 1 fon’ | statement number referred | 
| ee 
| Bit 2 'on' | referred to in an ASSIGN | 
| | statement | 
}------------ {——-——-—_—---------~----- { 
} Bit 3 {| not used | 
}------------ +~--------~------------------ { 
| Bit 4 fon" | statement number of a FCR- | 
| | MAT statement | 
}--------—--- {-—-------~--~----~---------- { 
| Bit 5 fon" | statement number of a GO | 
| | TO, PAUSE, RETURN, STOP, or| 
| | DO statement | 
|------------ }—--~-~~-------------------- { 
| Bit 6 ‘on' | statement number used as an| 
| | argument | 
<a aee ee EER ee ES { 
| Bit 7 "on" | statement number is the | 
| | object of a branch | 
Eanes ge ne Se ence aR ae J 
Figure 22. Function of Each Subfield in 


the Byte A Usage Field of a 
Statement Number Entry 


Byte B Usage Field: Tnis field is con- 
tained in the second byte of the second 
word. The byte B usage field indicates 
additional characteristics of the statement 
number for which the entry was constructed. 
The kyte B usage field is divided into 
eight subfields, each of which is one bit 
long. The bits are numbered 0 through 7. 
Figure 23 indicates the function of each 
sukfield in the byte B usage field. 


Pointer Field: This field contains a 
pointer to the text entry constructed by 
phase 10 for the associated statement 
number. 


Image Field: This field contains the 
binary representation of the statement num- 
ker for which the entry was created. 


MODIFICATIONS TO STATEMENT NUMBER ENTRIES: 
During the processing of subroutine LABTLU- 
IEKCLT and STALL-IEKGST in phase 10, phases 
15, 20, and 25, each statement number entry 
created by phase 10 is updated with infor- 
mation that describes the text block asso- 
During 


phase 10, if the XREF option is selected, 
LABTLU-IEKCLT makes changes in statement 
number dictionary entries for later use by 


XREF-IEKXRF. (See Figure 24.) 

Pe Agee a i a cam ay 1 
{| Subfield | Function | 
|------------ 4---------------------------- 
{| Bit O ‘on' | statement number is within | 
| | a DO loop and is trans- | 
| | ferred to from outside the | 
| | range of the DO loop | 
|------------ }---------------------------- | 
| Bit 1 ‘on' | compiler generated state- | 
| | ment number | 
|------------ 4---------------------------- { 
| Bats Z>5 | not used | 
|------------ {----------------------------1 
| Bit 6 ‘on | statement number appears in| 
| | END or ERR parameter of | 
| ] READ statement | 
}------------ +---------------------------- 1 
{| Bit 7 ‘on | statement number is used in| 
| | a computed GO TO staterent | 
eee cee ead ae eet Se yen Paine ieee NER a A rere Ne re ee j 


Subfield in 
Field of a 
Entry 


Function of Each 
the Byte B Usage 
Statement Number 


Figure 23. 


ee ene, SR ah a EE oe Fee ge Oe Cpe, Meer =, edt 7 
| | * | 
[--------- 4---------7--------- qonn nna 
|* | * \* |* | 
}--------- $---------1--------- 4-—--------- 
| | * | 
}--------- 4_-~-----~---------------------- 
[+ | 
Sa i a aa i a sl a a es Se ee et { 


|XREF puffer pointer - last entry | 


Raa ARE BA SR Poe ae ee { 
{|XREF buffer count |XREF buffer pointer- | 


| [first entry | 


|------------------- 4-----~--------------- { 
{Definition field , | 
|---------------------~------------------- { 
: | 
| Seguence chain field | 
a a a a tt a a em a eas 4 


Figure 24. Format of a Dictionary Entry 
for Statement Number After 
LABTLU-IEKCLT processing for 


XREF 


XREF Buffer Pointer - Last Entry: This 
field contains a pointer to the most recent 


XREF buffer entry for this statement number 
unless this dictionary entry is a defini- 
tion of a statement number. If this dic- 
tionary entry is a definition of a state- 
ment number, this field is not used. © 


XREF Buffer Count: This field contains a 
count of the number of times the XREF buff- 
er has been written out on SYSUT2 at the 
time this dictionary entry is modified by 
LABT LU-IEKCLT. 


XREF Buffer Pointer -— First Entry: This 
field contains a pointer to the first XREF 
buffer entry for this statement number. 


Definition Field: This field contains an 
ISN if this statement number dictionary 
entry corresponds to a definition of a 
Statement number. The field contains -1 if 
the statement number has been previously 
defined. 


Sequence Chain Field: This field chains 
the statement numbers in numerical order. 


Figure 25 illustrates the format of a 
Statement number entry after the procesSSing 
of STALL-IEKGST and phases 15, 20, and 25. 
Cnly changes are indicated; * stands for 
unchanged. 


= 4 bytes —————————— 


< 
| |New Chain field | 


|---------- +~--~----- ---------- 1--------- { 
| * | * {Block {|Loor | 
| | jStatus {number | 
| | |Field | | 
per anareee eee deere feed ee fee ee 
| {Address constant pointer field| 
}---------- 4—~-~~~--~---~-~-~------------- { 
| Image field | 
|---------- q7----------------------------- { 
| Loor {Text pointer field | 
|number | | 
|save area | | 
saat Boh aca Se ee ee eee 
|Forward connection field (ILEAD) | 
a see a eee el ee | 
|Backward connection field (JLEAD) | 
i eee Pala ge Ne ie ee | 


{Block size field (BSZ) | 

Me ote le ee tes ee Se ee ee J 

Figure 25. Format of Statement Number 
Entry After the Processing of 
Phases 15, 20, and 25 


New Chain Field: The new chain field con- 
tains a pointer to the entry for the state- 
ment number that is defined in the source 
module immediately after the statement 
number for which the statement number entry 
under consideration was constructed. 
(STALL-IFKGST modifies the phase 10 chain 
pointer when it rechains the statement 
number entries to correspond to the order 
in which statement numbers are defined in 
the source module.) This field is not 
modified by subsequent chases. 


Block Status Field: The block status field 
indicates the status of the text block 
associated with the statement number entry 
under consideration. The block status 
field is divided into eight subfields, each 
of which is one bit long. The bits are 
numbered 0 through 7. Figure 26 indicates 
the function of each subfield in the block 
Status field. 
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®@ Figure 26. 


eS eee 
| Subfield 


+ pede Sa eae aia aa 


ee eNO ea Pee cae ee en : 
Function | 


—~——----—----—-— --~—----— + --- { 
Used for various reasons | 
by the routines that | 
explore connections (e.g.,| 
the associated block has _ | 
previously been considered | 
in the search for the kLack| 
dominator of the block) | 


the associated block exits] 
from a loop | 
Ota OE NE NST STE RP eRe RY OE | 
the associated block is a | 
fork (i.e., it has two or | 
more forward connections) | 
Bit 4 | same as bits 0 and 1 | 
SS ae ee ee | 
the associated block is in| 
the current loop | 


the associated block has _ | 
been completely processed | 
along the OPT=2 path | 
eens See eer Neen ne Ne PELs eee | 
the associated block is an| 
entry block | 
aa ace eee ata ea He pac 
Function of Each Subfield in 
the Block Status Field 


Loop Number Field: The loop number field 
contains the number of the loop to which 
the text block (associated with the state- 
ment number entry under consideraticn) 
belongs. This field is set up and used ky 
phase 20. Just before the loop number is 
assigned, this field contains a depth 
number. 


Back Dominator Field: The back dominator 
field contains a pointer to the statement 
number entry associated with the back 
dominator of the text block associated with 
the statement number entry under considera- 
tion. This field, set up and used by phase 
20, occupies the address constant pointer 
field. 


Address Constant Pointer Field: The 
address constant pointer field (after phase 
25 processing) contains either: 


e An indication of a reserved register 
and a displacement, if branching opti- 
mization is being implemented and if 
the text block (associated with the 
statement number entry under considera- 
tion) can be branched to via an RX- 
format branch instruction (refer to the 
phase 20, "Branching Optimization"). 


e A pointer to the address constant 
reserved for the statement number 
(refer to phase 25, “ADCON Table Entry 
Reservation"). 
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Text Pointer Field: The text pointer field 
contains a pointer to the phase 15 text 
entry for the statement number with which 
the statement number entry under considera- 
tion is associated. This field is not used 
by phase 10; it is filled in by phase 15, 
and is unchanged by suksequent phases. 


Forward Connection Field (ILEAD): The for- 


ward connection field contains a rointer to 
the initial RMAJOR entry fer the blocks to 
which the text block associated with the 
Statement number entry under consideraticn 
connects. This field is set up by phase 15 
and used ky phase 20. A relative address 
f£ the block is stored in this field by 

phase 20. 


Backward Connection Field (JLEAD): The 


backward connection field contains a point- 
er to the initial CMAJOR entry fcr the 
blocks that connect to the text block asso- 
ciated with the statement number entry 
under consideration. This field is set up 
by phase 15 and used by phase 20. During 
phase 25 a relative location is stored in 
the field. 


DIMENSION ENTRY FORMAT: The format of the 
dimension entries constructed by phase 10 
is illustrated in Figure 27. 


Array size field | 


poses See ee sar asap leas enemas and een { 


|Dimension number |Element length field | 


|field | | 
(SaaS (reas eo= ere ea ee | 
| |First subscript pointer field | 
}--~------- |--~--~--~--------------------- 
| {Second subscript pointer field| 
}---------- }~--~--~-~-----—--------------- 
| {Third subscript pointer field | 
|---------- }-----~-------~---------------- 
| |Fourth subscript pointer field| 
[---------- $---~-------------------------- 
| [Fifth subscript pointer field | 
|--------—- +------------------------------ 
{ {Sixth subscript pointer field | 
|----—---- {------------------------------ { 
| {Used only for variable | 
| | dimensions | 
baie eet 5 NR ee oe Oe ee ee Sate ee nn en ee eee J 


Figure 27. Format of Dimension Entry 
Array Size Field: The array size field 
contains either the total size of the asso- 
Ciated array or zero, if the array has 
variable dimensions. 


Dimension Number Field: The dimension 
number field contains the number of dimen- 
Sions (1 through 7) of the associated 
array. 


Element Length Field: The element length 
field ccntains the length of each element 
(first dimension factor) in the associated 
array. 


First Subscript Pointer Field: The field 
contains either a pointer to the dictionary 


entry for the second dimension factor, 
which has a value of D1*L, (Refer tc 
“Appendix F: Address Computation for Array 
Elements") or a pointer to the dictionary 
entry for the first subscript parameter 
used to dimension tne associated array, 
that array has variable dimensions. 
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Second Subscript Pointer Field: This field 
contains either a pointer to the dictionary 


entry for the third dimension factor, which 
has a value of D1*D2*L, or a pointer to the 
second subscript parameter used to dimen- 
Sion the associated array, if that array 
has variable dimensions. This field is not 
used if the associated array has a single 
dimension.- 


Third Subscript Pointer Field: This field 
contains either a pointer to the dictionary 
entry for the fourth dimension factor, 
which has a value of D1*D2*D3*L, or a 
pointer to the third subscript parameter 
used to dimension the associated array, if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than three dimensions. 


Fourth Subscript Pointer Field: This field 
contains either a pointer to the dictionary 
entry for the fifth dimension factor, which 
has a value of D1*D2*D3*D4*L, or a pointer 
to the dictionary entry for the fourth sub- 
script parameter used to dimension the 
associated array, if that array has vari- 
able dimensions. This field is not used if 
the associated array has fewer than four 
dimensions. 


Fifth Subscript Pointer Field: This field 
contains either a pointer to the dictionary 


entry for the sixth dimension factor, which 
has a value of D1¥*D2*D3*D4*D5*L, or a 
pointer to the dictionary entry for the 
fifth subscript parameter used to dimension 
the associated array, if that array has 
variable dimensions. This field is not 
used if the associated array has fewer than 
five dimensions. 


Sixth Subscript Pointer Field: This field 
contains either a pointer to the dictionary 


entry for the seventh dimension factor, 
which has a value of D1*D2*D3*D4+D5*D6*FL, 
or a pointer to the dictionary entry for 
the sixth subscript parameter used to 
dimension the associated array, if that 
array has variable dimensions. This field 
is not used if the associated array has 
fewer than Six dimensions. 


Pointer To Last Subscript Parameter: MThis 
field contains a pointer to the dictionary 


entry for the seventh subscript parameter 
used to dimension the associated array, if 
that array has variable dimensions. This 
field is not used if the associated array 
has fewer than seven dimensions. 


Common Table 


~The common table contains: 1) common 
block name entries, which describe common 
blocks, 2) equivalence group entries, which 
describe equivalence groups, and 3) equiva- 
lence variable entries, which describe 
equivalence variables. 


COMMON BLOCK NAME ENTRY FORMAT: The format 
of the common block name entries con- 
structed by phase 10 is illustrated in 
Figure 28. 


Chain Field: The chain field is used to 
Maintain linkage between the various common 
block name entries. It contains either a 
pointer to the next common block name entry 
or an indicator (zero), which indicates 
that additional common blocks have not yet 
been encountered. 


P1 Field: The P1 field contains a pointer 
to the dictionary entry for the first vari- 
able in this common block. 


P2 Field: The P2 field contains a pointer 
to the dictionary entry for the last vari- 
able in this common block. 


Name Field: The name field contains the 
name (xight-justified) of the common block 
for which this common block name entry was 
constructed. 


Character Number Field: The character 
number field contains the number of charac- 
ters in the common block name. 


ISN Field: The ISN field contains the ISN 
assigned to the statement in which this 
common block name first occurs. 


iat atari TY Ny ye: Aa 


eG ee Ss ag aa 1 
| {Chain field | 


}---------- Cor caer al ge ace { 
| {P1 field | 
|---------- $--------~--------------------- | 
| |P2 field | 
}---------- 4——~~-------~--~-------------- { 
| Name field | 
a a ee | 
| Name field | 
~-~----------------- qyo7----------- === === 4, 
|Character Number J|ISN field | 
|field | | 
hl da a Sh ee H (Seatten en celyeere eh even Weer ieee Patan eres J 

@ Figure 28. Format of a Common Block Name 

Entry 
Appendix A: Takles 123 


MODIFICATIONS TO COMMON BLOCK NAME ENTRIES: 
During compilation, certain fields of com- 
mon block name entries may be modified. 
Figure 29 illustrates the format of a com- 
mon block name entry after common block 
processing by STALL-IEKGST. Only changes 
are indicated; * stands for unchanged. 


en Note ee p= oe py fae ee ey ee 1 
| his | 
[oa a =a fae ae ee ! 
| i | 
[---------- +-------——----—----------— 
| {Total size of common block | 
}---------- Bn nn { 
| * | 
}----------------—------__---------------- { 
| * | 
fan an Pon { 
i a | 
BB ae ait SL sce i et ee 4 


Format of Common Block Name 
Entry After Common Block 
brocesSing 


Figure 29. 


EQUIVALENCE GROUP ENTRY FORMAT: The format 


of the equivalence group entries con- 
structed by phase 10 is illustrated in 
Figure 30. 


Indicator Field: The indicator fieid is 
nonzero if a variable in this group is sub- 
scripted and its dimension statement has 
not been processed. 


Chain Field: The chain field is used to 
maintain linkage between the various equiv- 
alence groups. It contains a pointer to 
the next equivalence group entry. 


fc eS Sl A a aC al a aoa 1 
{indicator | Chain field | 
|field | | 
}~--------- 4——--------~-------~----------- { 
| P1 field | 
| --------------~-----~-------------------- { 
| Used by phase 15 | 
|------~-----~---~------------------------ { 
| ISN field | 
Me Sogo Di er es a eee ee es eae J 
Figure 30. Format of an Equivalence Group 
Entry 


P1 Field: The P1 field contains a pointer 
to the equivalence variable entry for the 

first variable in the equivalence group or 
for the first variable in the common block. 


ISN Field: The ISN field contains the ISN 
assigned to the statement in which any name 
of the ZQUIVALENCE group first occurs. 
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e Figure 32. 


MODIFICATIONS TO EQUIVALENCE GRCUP ENTRIES: 
During compilation, certain fields of 
equivalence group entries may be modified. 
Figure 31 illustrates the format of an 
equivalence group entry after equivalence 
processing by STALL-IEKGST. Only changes 
are indicated; * stands for unchanged. 


ee, SEG Pe Oe Farge OP te op par ee ee ee eee Te 7 
ae | 
= | 
}----------------------------------------- { 


| group | 


Figure 31. Format of Equivalence Group 
Entry After Equivalence 


Processing 


EQUIVALENCE VARIABLE ENTRY FORMAT: The 


format of the equivalence variable entries 
constructed by phase 10 is illustrated in 
Figure 32. 


Indicator Field: The indicator field is 
nonzero if the equivalence variakle is sub- 
Scripted prior to being dimensicned. 


Pi Field: The P1 field contains a pointer 
to the dictionary entry for this equiva- 
lence variakle. 


Number of Subscripts Field: The number of 
subscripts field contains the total number 


of subscripts used by a variable being 
equivalenced, with subscripts, prior to 
being dimensioned. 


ees i Sa 


(eee ApS eee ee eo ep ee 1 
{Indicator | P1 field | 
|field | | 
~~-------- }----~-~----~—--~--------------f 
{Number of | Chain field | 
|sukscripts|]| | 
}---------- bia een { 
| Offset field | 
|-------------—----—---------------------- { 


Format of Equivalence Variable 
Entry 


Chain Field: The chain field is used to 
Maintain linkage between the various 
variables in the equivalence group. It 
contains a pointer to the equivalence vari- 
able entry for the next variable in the 
equivalence group. 


Offset Field: The offset field contains 
the displacement of this variable from the 
first element in the equivalence group. 


Subscript Field: The subscript field(s) 
contains the actual subscript (s) specified 
for a variable being equivalenced, with 
subscripts, prior to being dimensioned. 


MODIFICATIONS TO EQUIVALENCE VARIABLE 
ENTRIES: During compilation, certain 
fields of equivalence variable entries may 
be modified. Figure 33 illustrates the 
format of an equivalence variakle entry 
after equivalence processing by STALL- 
IEKGST. Only changes are indicated; * 
Stands for unchanged. 





aia De ee a re 1 
| * | * | 
|---------- $~----------------------------- { 
| [* | 
[ee See SN a he a Se 
{Displacement of variable from group head | 
|--~--~------------------------+---------- { 
|* | 
|----------------------------------------- { 
* | 
GN ae ea ie ee 4 


Figure 33. Format of Equivalence Variable 
Entry After Equivalence 


Processing 
Literal Tabie 


The literal table contains literal con- 
Stant entries, which describe literal con- 
stants used as arguments in CALL state- 
ments, and literal data entries, which 
describe the literal data appearing in DATA 
Statements. (Entries for literal data 
appearing in DATA statements are not 
chained. They are pointed to from data 
text.) 


LITERAL CONSTANT ENTRY FORMAT: The format 


of the literal constant entries constructed 
by phase 10 is illustrated in Figure 34. 


a ll eS a ree 


Ge ee ee tr EY eg Re 1 
| Chain field | 
SRA asa emeceie [na Ne see ce 1 
| Length }255 {Used by phase 15 | 
|field | | | 
a en aera ee ee ee oe Sa | 
| Literal constant field | 
a ct ee See Se PR Led ee ee J 
Figure 34. Format of Literal Constant 
Entry 


Chain Field: The chain field is used to 
maintain linkage between the various liter- 
al constant entries. It contains a pointer 
to the previous literal constant entry. 


The length field contains 
of the literal 


Length Field: 
the length (in bytes) 


constant. 


Literal Constant Field: The literal con- 
stant field contains the actual literal 
constant for which the entry was con- 
Structed. The field ranges from 1 to 255 
bytes (1 character/byte, left-justified) 
depending on the size of the literal 
constant. 


MODIFICATIONS TO LITERAL CCNSTANT ENTRIES: 
During compilation, certain fields of lit- 
eral constant entries may be modified. 
Figure 35 illustrates the format of a lit- 
eral constant entry after relative address 
assignment by CORAL, the second segment of 
phase 15. Only changes are indicated; * 
Stands for unchanged. 


——____—_—_—— 4 bytes ———__________» 


SE ee ae a gam a mee Bees Oy ay wer tr 1 
Ty | 
|---------- ¥--------- qo77----------------- { 
| * | [Displacement from | 
{ [ jassociated address | 
| | | constant | 
Peete eas= Bs Sees ate oh a A as sl se ta ei ee | 
|* | 
Beso alas Se a Eh ce as oe ee 4 
Figure 35. Format of Literal Constant 
Entry After Relative Address 
Assignment 
LITERAL DATA ENTRY FORMAT: The format of 
the literal data entries constructed by 
phase 10 is illustrated in Figure 36. 
re a ne era ee ee Pe pee eo a 1 
| Length field (1 byte) | 
a eer Wi a ee oe ae Foe Sepa i Ne PL | 


Figure 36. Format of Literal Data Entry 
Length Field: The length field contains 
the length (in bytes) of the literal data 
for which the entry was constructed. 


Literal Data Field: The literal data field 
contains the actual literal data. The 
field ranges from 1 to 255 kytes (1 
character/byte, left-—justified) depending 
on the size of the literal data. 


Branch Takle 


The branch table contains initial branch 
table entries and standard branch table 
entries. An initial branch table entry is 
constructed by phase 10 as it encounters 
each computed GO TO statement of the source 
module. Standard branch table entries are 
constructed by phase 10 for each statement 
number appearing in the computed GO TO 
statement. 
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INITIAL BRANCH TABLE ENTRY FORMAT: The 
format of the initial branch table entries 
constructed by phase 10 is illustrated in 
Figure 37. 


OS Dyes a se 


Rare mae Weg eas Pie re OE eed Te 1 
{Indicator |Chain field | 
{field | | 
|---------- 4——-----~---~------------------ { 
| P1 field | 
|----------------------------------------- { 
| Used by phase 25 | 
|--~---~--~------------------------------- { 
| Used by phase 25 | 
‘ee PR A re et rel Ne OP een a ae J 
Figure 37. Format of Initial Branch Table 
Entry 


Indicator Field: The indicator field is 
nonzero for an initial branch table entry. 
This indicates that the entry is for 
compiler-generated statement number for the 
"fail-through" statement. (The falli- 
through statement is executed if the value 
of the control variable is larger than the 
numoper of statement numbers in the computed 
GO TO statement.) 


Chain Field: The chain field is used to 
maintain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 


P1 Field: The P1 field contains a pointer. 
to the statement number/array table entry 
for the compiler-generated statement number 
for the fall-through statement. 


MODIFICATIONS TO INITIAL BRANCH TABLE 
ENTRIES: During compilation certain fields 
of initial branch table entries may be 
modified. Figure 38 illustrates the format 
of an initial branch table entry after the 
processing of phase 25 is complete. Only 
changes are indicated; * stands for 
unchanged. 


ee eg ae Se te et ee Her pee wer ag 7 
|* \* | 
}---------- 4_—----------~----------------- { 
|* | 
ey a ee a a a ea a a a cals te ae a lt a ec { 


{Relative address of statement associated | 
{with fall-through statement number | 


|Pointer to address constant reserved for | 
|fall-through statement number | 


Format of Initial Branch Table 
Entry After Phase 25 
Processing 


Figure 38. 


STANDARD BRANCH TABLE ENTRY FORMAT: — The 
format of the standard branch table entries 
constructed by phase 10 is the same as the 
format for initial branch table entries. 
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Indicator Field: 


Chain Field: 


P1 Field: 


Function Name Field: 


This field is zero for 
standard branch table entries. 


This field is used to main- 
tain linkage between the various branch 
table entries. It contains a pointer to 
the next branch table entry. 


The P1 field contains a pointer 
to the statement number/array takle entry 
for the statement number (appearing in a 
computed GO TO statement) for which the 
Standard branch table entry was 
constructed. i | 


MODIFICATICNS TO STANDARD BRANCH TABLE 
ENTRIES: 


During compilation, certain 
fields of standard branch table entries may 
ke modified. Figure 39 illustrates the 
format of a standard branch table entry 
after the processing of phase 25 is com- 
plete. Only changes are indicated; * 
stands for unchanged. 


rsh yy OG eae 


Fao re Me sarc ee Gy ee te 7 
|* |* | 
}---------- 4_—---------------------------- 
|* | 
cS aS ee i a em a cea Se tee eae ea Se eee { 


|Relative address of statement associated | 
Jwith this statement number | 


Format of Standard Branch Table 
Entry After Phase 25 
Processing 


Figure 39. 


SUBPROGRAM TABLE 


The subprogram table (IEKLFT) contains 
entries for the IBM supplied subprograms 
and in-line routines. The subprogrars 
reside on the FORTRAN system library (SYS1. 
FORTLIB), while the in-line routines are 
expanded at compile time. The subprogram 
takle is used by phase 15 to determine the 
validity of the arguments to the 
subprogram. 


Each entry in the subprogram table (see 
Table 22) contains two fields: index field 
(2 bytes) and function name field (6 
bytes). : | 


This field contains 
the names of all library and in-line func- 
tions. It is searched in ascending order 
beginning with field 1 and then with field 
2. Field 1 contains the four low-order 
characters of the name; field two contains 
the two high-order characters of the name. 


e Table 22. 


Subprogram Table - IEKLFT 
(2,128) 


— in —— 7 


Function Name 
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Index Field: This field contains a pointer 
to entries in the following tables: 


This table contains 128 1- 
byte entries pointing back to 
the subprogran table. 


FUNTB1 (128) 


This table contains 128 1- 
byte entries which give the 
mode of the arguments for all 
library and in-line 
functions. 


FUNTB2 (128) 


This table contains 60 1-byte 
entries which give the mode 
of the result for all in-line 
functions. The first 68 
bytes of the table are not 
used. 


FUNTB3 (128) 


FUNTB4 (68) This table contains 68 4-byte 
locations reserved for dic- 
tionary pointers to library 


routines. 


TEXT OPTIMIZATION BIT TABLES 


There are nine major bit tables used. 
extensively throughout text optimization. 
These tables (each four words or 128 bits 
in length) contain bits that are preset. 
Only the first 86 bit positions in each 
table are meaningful and each of these is 
associated with a particular text entry 


operator. The settings (on or off) given 
to these cits indicate either the validity 
of operand positions in a text entry with a 
particular operator or the candidacy of a 
text entry with a particular operator for 
text optimization procedures. 


Three of these tables, MVW, MVU, and MVV 
are tested by subroutine KORAN-IEKOKO and 
indicate the validity of the operand posi- 
tions in a text entry with a given opera- 
tor. The MVW table indicates the validity 
of the operand 1 position; the MVU table 
indicates the validity of the operand 2 
position; and the MVV table indicates the 
validity of the operand 3 position. For 
example, if the bit in MVW that corresponds 
to a particular operator is on, then the 
operand 1 position of a text entry having 
that operator contains a valid or actual 
operand. If the bit is off, the operand 1 
position of the text entry does not contain 
an actual operand. (In the latter case, 
the operand 1 position may still contain 
information that is pertinent to the text 
entry; however, it does not contain an 
actual operand.) 


The remaining six tables, MBM, MSGM, 
MGM, MXM, MSM, and MBR are also tested by 
Subroutine KORAN-IEKQOKO and indicate the 
candidacy of a text entry with a particular 
operator for text optimization procedures. 
The MBM table indicates whether or not text 
entries with a particular operator are to 
be considered for backward movement; the 
MXM table indicates whether or not text 
entries with a particular operator are to 
be considered for common expression elimi- 
nation; the MSM table indicates whether or 
not text entries with a particular operator 
are to be considered for strength reduc- 
tion; and the MBR takle indicates whether 
or not the operator is a branch. 


The text optimization bit tables are 
illustrated in Table 23. In this table, 
the operator associated with each bit posi- 
tion in the bit tables is identified. The 
kits settings for each operator as they 
appear in the bit tables is also shown. An 
X Signifies that the bit is on; a blank 
Signifies that the bit is off. 
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Text Optimization Bit Tables 
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DIM 
MOD 
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REGISTER ASSIGNMENT TABLES 


The register assignment tables are a set 
of one-dimensional arrays used by the full 
register assignment routines of phase 20. 
There are three types of tables: local 
assignment tables (refer to Table 24), 
global assignment tables (refer to Takle 
26), and register usage tables. The 
register usage tables are work tables used 
by the local and global assignment routines 
in the process of full register assignment. 


Register Use Table 


The format of the register use tables, 
TRUSE and RUSE, are the same for the local 
and global assignment routines. Each table 
is sixteen words long. Words 1 through 11 
represent general registers 1 through 11, 
words 12, 14, and 16 represent floating 
point registers 2, 4 and 6, and words 13 
and 15 are unused. 


Table 24. Local Assignment Tables 


ree eM ae a a eee Te te 
Function JOrigin' | 


| 

| J {Serves as index to TXP, BVP, |FWDPAS- | 

| |BVRA, BVA. | ITEKRFP | 

| | 

P |Gives the storage location |FWDPAS- 
jof the text item associated |IEKRFP 
{with each value of J. | 

Pp 


| 
BVP |Contains the MCOORD value | FWDPAS- 
jassociated with operand 1 of |IEKRFP 


|the text item represented by| 


[J. | 
a | | 
BVRA|Indicates the register | BKPAS- 
|locally assigned to the | TIEKRBP 
| 
BVA |Represents the activity | FWDPAS- 
{within the block of the | LEKRFP 


|quantity represented by J; | 
Jalso contains indicator bits| 
|describing the quantity. | 
{See Table 25. | 


| 
WJ2 |Indicates whether a variable|FWDPAS- 
{is eligible for local | TEKRFP 
Jassignment. Indexed via the| 
{MCOORD values obtained from | 
| BVP. | 
bade ese eee i eae eye ae 
|*This column indicates the name of the | 
| register assignment routine that ini- | 
| tially creates the particular table. | 
|2Although WJ is distinctly a local | 
assignment table, it is indexed by the | 
| 
| 
| 
| 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| | 
| {quantity represented by J. | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


en 


quantity MCOORD (which is used to index 
the global assignment tables) rather 
than by the local assignment table 
index, J. 


eTable 25. BVA Table 


Ee ee ee an a ey Re ee ay Se 1 
|Bit|Meaning | 
|---4------------------------------------- { 
|} O {Not used. | 
| | | 
| 1 |Text item is candidate for forward | 
| |wovement. | 
| | | 
| 2 |Not used. | 
| | 
| 3 |Inhibit ‘inter-Llock' register | 
| jJassignment for text item. | 
| | 
} 4 |Text item is candidate for ‘inter- | 
| [block"' register assignment. | 
| | | 
| 5 |Text item is candidate for floating | 
| |point downgrading if a CALL is found. | 
| | | 
| 6 |Text item is candidate for register | 
| |classification. | 
| | | 
{| 7 {P1 is the result of an integer mod | 
| | function. { 
| | 
| 8 |The operand has been encountered | 
| | before. 
| | | 
| 9 |Text item is the imaginary result of | 
| la complex function. | 
| | | 
{10 |The operand is defined by a function | 
| [call. | 
| | 
[11 |P1 is floating point. | 
| | | 
}12 |P1 is the result of an integer mul- | 
| {tiply or divide. | 
| | | 
113 |Zero length temporary indicator. | 
| | | 
114 {Case II subscript indicator is | 
| {changed to a Case II. | 
| | 
J15 | | 
ee _ | 
| |BVA - Local Activity. | 
| - | | 
{31 | | 
}---1------------------------------------- { 
{|The BVA table consists of a fullword for | 
leach text in the block. | 
Da pt eh Nate ioe ee te eae ot ta ne a Bet ees Sd J 


If the contents of TRUSE (i) and RUSE (i) 
is equal to zero, then register i is avail- 
akle for assignment. If the value con- 
tained in TRUSE(i) or RUSE(i) is between 2 
and 128, inclusive, then the register i is 
assigned to the variable whose MCCORD value 
is equal to the contents of TRUSE (i) or 
RUSE (i). If the contents of TRUSE(i) or 
RUSE (i) has a value between 252 and 255, 
register i iS unavailable for assignment 
and is reserved for special use (see next 
paragraph). 2 
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Table 26. Global Assignment Tables 


ae a eg tga ee ee eg ee re ree ae wee 1 
[Name | Function 


| MCOORD|Serves as an index to |Phase 15 
{|MVD, EMIN, RA, RAL, WABP,| . 

{WA and WJ. | 

fo 
{Gives the location of the|Phase 15 
{dictionary entry for the | 
{variable associated with 

jthe given value of 

| MCCORD. 


; 


REGAS- 
LTEKRRG 


| 

| Indicates whether the 
j|variable associated with 
{a particular MCOORD value 
fis eligible for global 
jassignment. 

| 
{Indicates the number of 
jthe first register glob- 


| 

| 

| 

| 
EMIN | 
| 
| 
| 
| 
| 
| 
| 
{ally assigned to the | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


GLOBAS - 
IEKRGB 


vs) 
p> 


{variable represented by. 
{the MCCORD value; pro- 
{vides continuity in glob- 
Jal assignment from inner 
{to outer loops. 
| 
| Indicates the register 
{globally assigned to the 
|variable represented by 
Jthe MCCORD value. 
| 
| Indicates the total | FWDPAS- 
factivity for the variable] IEKRFP 
{represented by the MCOORD| 
|value. Calculated by | 
Jadding 4. to the value | 
Jeach time a definition of | 
{the variable is encoun- | 
{tered and adding 3. to | 

| 

| 


GLOBAS- 
IEKRGB 


pe) 
> 
tt 


= 
an 


{the value for a use of 
{tne variable. 


| | 
|Indicates the activity of |FWDPAS- 
jbase variables. Calcu- |IEKRFP 
{lated in the same manner | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
( 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
WABP | 
| 
| 
| 
dj 


Pes oe ee oe ee ee ee ee ee ee eee ee ee ee ee ee ee oe ee ee ee ee ee ee ee ee ee ee ee ee ee ee es I ee coe oe 


Register Use Considerations: Registers 15 
and 14 are not available for use by 


register assignment. They are reserved, 
and used for branching during the execution 
of the object module resulting from the 
compilation. 


Register 13 is not available for use by 
register assignment. It is reserved, and 
used during the execution of the object 
module to contain the address of the save 
area set. aside for the object module (refer 
to Fortran System Director, “Generation of 
Initialization Instructions"). Register 13 
is also used to refer to: 


e Branch tables for computed GO TOs. 
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e Parameter list for external references. 
e Local constants, variables and arrays. 
e Adcons for external references. 


If the abcve items exceed 4096 bytes, 
the adcons are referred to by register 12. 


Register 12 1S not available for use by 
register assignment. It is set aside to 
contain the starting address of the "Con- 
stants" portion of text information. 


Registers 11, 10, and 9 may or may not 
be available for use by register assign- 
ment. Their use depends upon the number of 
required reserved registers. (Refer to 
phase 20, “Branching Optimization"). 


NAMELIST DICTICNARIES 


Namelist dictionaries are developed by 
CORAL for the NAMELIST statements appearing 
in the source module. These dictionaries 
provide IHCNAMEL with the information 
required to implement READ/WRITE statements 
using NAMELISTs. The namelist dictionary 
constructed by CORAL from the phase 10 
namelist text representation of each NAME- 
LIST statement contains an entry for the 
nainelist name and entries for the variables 
and arrays associated with that name. 


NAMELIST NAME ENTRY FORMAT: The format of 
the entry constructed for the namelist name 
is illustrated in Figure 40. 


re a a a ge Oe ee ee 1 
(2 words) 
aah a a ee ne tt J 


Figure 40. Format of Namelist Name Entry 


Name Field: The name field contains the 
namelist name, right-justified, with lead- 
ing Elanks. | 


NAMELIST VARIABLE ENTRY FORMAT: The format 
of the entry constructed for a variable 
appearing in a NAMELIST statement is illus- 
trated in Figure 41. 


a a a Sag a a 7 
| Name field (2 words) | 
ae aT Is air EN ERR PEY Saeed EP SO fo Oe 4 
| Address field (1 word) | 
meg aeeseaanaarees | eee oo a 
} Item Type | Mode. | Not used | 
| field | field | (2 bytes) | 
| (1 byte) | (1 byte) | | 
ee spree area ae eee Weg RP tien en oe) Sea RC eee nae ee ae eee 
Figure 41. Format of Namelist Variakle 


Entry 


Name Field: The name field contains the 
name of the variable, right-justified, with 
leading blanks. : 


Address Field: The address field contains 
the relative address of the variable. 


Item Type Field: This field is zero fora 


variable. 


Mode Field: The mode field contains the 
mode of the variable. 


NAMELIST ARRAY ENTRY FORMAT: The format of 
the entry constructed for an array appear- 
ing in a NAMFLIST statement is illustrated 
in Figure 42. 


| Name field (2 words) | 
Paes eee eee eee 
| Address field (1 word) | 
pea eee caesar aan ok | Se ea | eee 
| Item Type| Mode {| Number of {Element | 
| field | field | dimensions|length | 
| | | field | field | 
| (1 byte) | (1 byte) {| (1 byte) | (1 byte) | 
}---------~ {--------- 4---—--—---— 4————--—- { 
| Indicator | First dimension | 
| field | factor field | 
| (1 byte) | (3 bytes) | 
}---------~ {-----—---__-__----—--—---- { 
| Not used | Second dimension | 
| | factor field | 
| (1 byte) | (3 bytes) | 
|---------- }------------------------------ { 
{| Not used | Third dimension | 
| factor field | 
| (1 byte) | (3 bytes) | 
Dare eet ee ee as estas a ee a a 
| Etc. (refer to "Dimension Entry Format") | 


Figure 42. Format of Namelist Array Entry 
Name Field: The name field contains the 
name of the array, right-justified, with 
leading blanks. 


Address Field: The address field contains 
the relative address of the beginning of 
the array. 


Item Type Field: This field is nonzero for 


an array. 


Mode Field: This field contains the mode 
of the elements of the array. 


Number of Dimensions Field: This field 
contains the number of dimensions (1 
through 7) of the associated array. 


Element Length Field: The element length 
field contains the length of each element 
in the associated array. 


Indicator Field: This field is zero if the 
associated array has variable dimensions; 
otherwise, it iS nonzero. 


First Dimension Factor Field: If the asso- 
ciated array does not have variable dimen- 
Siens, this field contains the total size 
of the array. If the array has variable 
dimensions, this field contains the rela- 


tive address of first subscript parameter 
used to dimension the array. 


Second Dimension Factor Field: If the 
associated array does not have variable 
dimensions, this field contains the loca- 
tion of the second dimension factor (D1*IL). 
If the array has variable dimensions, this 
field contains the relative address of the 
second subScript parameter used to dimen- 
Sion the array. 


Third Dimension Factor Field: If the asso- 
Ciated array does not have variable dimen- 
Sions, this field contains the location of 
the third dimension factor (D1*D2*L). If 
the array has variakle dimensions, this 
field contains the relative address of the 
third subscript parameter used to dimension 
the array. 


DIAGNCSTIC MESSAGE TABLES 


There are two major diagnostic tables 
associated with error message processing by 
phase 30: the error table and the message 
pointer table. 


ERROR TABLE 


The error table is constructed by phases 
10 and 15. AS source statement errors are 
encountered by these phases, corresponding 
entries are made in the error takle. Each 
error table entry consists of 2 one-word 
fields. The first field contains either an 
internal statement number, if the entry is 
for a statement that iS in error, a dic- 
tionary pointer, if the entry is for a sym- 
bol that iS in error (e.g., a variable that 
iS incorrectly used in an EQUIVALENCE 
Statement), or a statement number, if the 
entry is for an undefined statement number; 
the second field contains the message num- 
ber associated with the particular error. 
The message numbers that can appear in the 
error takle are those associated with mes- 
sages of error code levels 4 and 8 (refer 


to the publication IBM System/360 Operating 
system: FORTRAN IV (H) Programmer's 


Guide). 


MESSAGE POINTER TABLE 


The message pointer table contains an 
entry for each message number that may 
appear in an error table entry. Each entry 
in the message pointer table consists of a 
Single word. The high-order byte of the 
word contains the length of the message 
associated with the message number. The 
three low-order bytes contain a pointer to 
the text for the message associated with 
the message number. 
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APPENDIX B: INTERMEDIATE TEXT 


Intermediate text is an internal repre- 
sentation of the source module from which 
the machine instructions of the object 
module are generated. The conversion from 
intermediate text to machine instructions 
requires information about variables, con- 
Stants, arrays, Statement numbers, in-line 
functions, and subscripts. This informa- 
tion, derived from the source statements, 
is contained in the information table, and 
is referred to by the intermediate text. 
The information table supplements the 
intermediate text in the generation of 
machine instructions by phase 25. 


PHASE 10 INTERMEDIATE TEXT 

Phase 10 creates intermediate text (in 
operator-operand pair format) for use as 
input to subsequent phases of the compiler. 
There are six types of intermediate text 
produced py phase 10: 


e Normal text - the operator-operand pair 
representations of source statements 
Other than DATA, NAMELIST, DEFINE FILE, 
FORMAT, and Statement Functions (SF). 


e Data text - the operator - operand pair 
representations of DATA statements and 
the initialization constants in expli- 
cit type statements. 


e Namelist text - the operator-operand 
pair representations of NAMELIST 
Statements. 


e Define file text - the cperator-operand 
pair representation of DEFINE FILE 
statements. 


e Format text - the internal representa- 
tions of FORMAT statements. 


e SF skeleton text - the operator-operand 
pair representations of statement func- 
tions uSing sequence numbers as 
operands of the intermediate text 
entries. The sequence numbers replace 
the dummy arguments of the statement 
functions. This type of text is, in 
effect, a “skeleton"“ macro. 


Note: Intermediate text representations 
are, for sub-block allocation, divided into 
only two main types: Special (DATA, NAME- 
LIST, DEFINE FILE, FORMAT, and SF skeleton 
text), and normal (text other than special 
text). The intermediate text representa- 
tions are comprised of individual text 
entries. Each intermediate main text type 
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is allocated unigue sub-blocks of main 
Storage. The sub-blocks that constitute an 
intermediate text area are obtained by 
phase 10, as needed, via requests to the 
FSD (see FORTRAN System Director, “Storage 
Distribution"). 


Intermediate Text Chains 


Each intermediate text area (i1.e., the 
sub-blocks allocated to a particular type 
of text) is arranged as a chain, which 
links together (1) the text entries that 
are developed and placed into that area, 
and (2) in some cases, the intermediate 
text representation for individual 
Statements. 


The normal text chain is a linear chain 
of normal text entries; that is, each norm- 
al text entry is pointed to by the pre- 
viously developed normal text entry. 

The data text chain in bi-linear. This 
means that: 


1. The text entries that constitute the 
intermediate text representation of a 
DATA statement are linked by means of 
pointers. Each text entry for the 
statement is pointed to by the pre- 
viously developed text entry for the 
statement. 


2- The intermediate text representations 
of individual DATA statements are 
linked by means of pointers, each 
representation being pointed to by the 
previously developed representation. 
(A special chain address field within 
the first text entry developed for 
each DATA statement is reserved for 
this purpose.) 


The namelist text chain operates in the 
Same manner as the data text chain. 


The define file text chain is a linear 
chain of define file text entries, each 
define file text entry is pointed to by a 
previously developed define file text 
entry. A zero chain Signals the end of all 
define file text for a program. 


The format text chain consists of link- 
ages between the individual intermediate 
text representations of FORMAT statements. 
The pointer field of the second text entry 
in the intermediate representation of a 
FORMAT statement points to the intermediate 
text representation of the next FORMAT 
statement. (The individual text entries 


comprising the intermediate text represen- 


tation of a FORMAT statement are not 


chained.) 


The SF skeleton text 


only in that each text entry developed for 
an operator-operand pair within a particu- 
lar statement function iS pointed to by the 
previous text entry developed for that same 
The intermediate text 


statement function. 


chain is linear 


representations for separate statement 


functions are not chained together. 
a skeleton can readily be obtained by 
means of the pointer contained in the dic- 

tionary entry for the name of the statement 


er, 


function. 


Format of Intermediate Text Entry 


Those statements that undergo conversion 
from source representation to intermediate 


text representation are 


divided into 


operator-operand pairs, or text entries. 
Figure 43 illustrates the format of an 


intermediate text entry 
phase 10. 


constructed by 


Howev- 


+ 4 pytes ————________—___> 


‘are cee Meg 1 
|Adjective | | 
{|code field|Chain field | 
{| (Operator) | | 

pee aes ai aa host ee ee { 
{Mode field IType field | 
‘meena ae 1 a ea naa ae ee eee { 
{0 }Pointer field (operand) | 
emer ene eee he Sc hc aa toe eee eee J 


eFigure 43. 


Adjective Code Field: 


Intermediate Text Entry Format 


The adjective code 


field corresponds to the operator of the 


operator-operand pair. 


Operators are not 


entered into text entries in source form; 
they are converted to a numeric value as 


specified in the adjective code table 
It is the numeric representa- 


Table 27). 


tion of the source operator that actually 


is inserted into the text entry. 
(operators that define the 
nature of source statements) 


adjective codes 
numeric values. 


Chain Field: The chain 


maintain linkage between intermediate text 
It contains a pointer to the next 


entries. 
text entry. 


Mode and Type Fields: 
fields contain the mode 


operand of the text entry. 


Primary 


also have 


field is used to 


The mode and type 


and type of the 
Both items 


appear aS numeric quantities in a text 
entry and are obtained from the mode and 
type table (see Tables 20 and 21). 


Pointer Field: 


The pointer field contains 


a pointer to the information table entry 
for the operand of the operator-operand 


pair. 


However, if the operand is a dummy 


(see 


argument of a statement function, the 


pointer field contains a sequence number, 
which indicates the relative position of 


the argument in the argument list. 


Note: 
ments are not of the 
text entries consist 
the FORMAT statement 
into successive text 


eTable 27. 


The text entries for FORMAT state- 
FORMAT 
of the characters of 
in source form packed 


Adjective 


| Mnemonic 


[Code (in| (where 
| decimal) |agplicable) 


e— oe ee ee ee ee ce ee ce ee ee ee ee ee ee ee ce ee ce oe ce eee ee ee ee ee ce ee ee ee ee ee ee ce ee eee ee ee ee eee ae ee 


10 
11 
12 
13 


14 


16 


17 


18 
19 
20 
21 


22 


25 


26 


71 


sbO« 
-LT. 
«GT. 


NE. 


b= YH 
: 


Appendix B: 


above form. 


entries. 


AND 


{Right arithmetic 
{parenthesis 

| 

| OR 

| 

{Equal sign 

| 


| Comma 


| 
| Plus 


|Minus 

| 
|Multiply 
| 

|Divide 

| 


| Exponentiation 


|Function parenthesis 


j|Less than or equal 


{Greater than or 
|equal 


| 
| Equal 


J|Less than 


|Greater than 


| 
{Not equal 


[Left subscript 
|parenthesis 

| 

{Left arithmetic 
[parenthesis 


| 
|End mark 


| 
{GO TO, and implied 


| branches 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


fen cumeere GORE cxpeee SEED qn SOEEED MESS SEE ES ep SEE eee SEED GSES Gre SOE RES SESS gen EES ES ee SS Se SS GD SUES meee GED SEES OED emus atte SEES cum GES Gene cae, SEE qm, SEEDS quem ERED cumees SES umes ae 


(Continued) 


Intermediate Text 
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eTable 27. Adjective Codes (Continued) 

for eer Eee gta a RE pe 1 
| | Mnemonic | | 
|Code (in| (where | | 
{|decimal) |applicable) | Meaning | 
}-------- {----------- +-------------------- | 
| 193 | |BLOCK DATA | 
| | | | 
{| 205 = | | DATA | 
| | | 
| 208 | | SUBROUTINE, | 
| | |FUNCTION, or ENTRY | 
| | | | | 
| 209 | |FORMAT (text) | 
| | | | 
| 210 | JEnd of I/O list | 
| | | | 
{| 211 | | CONTINUE | 
| | | | 
| 212 | {Relative record | 
| {number | 
| | | 
| 213 | {Object time format | 
| | | variable | 
| | | | 
{| 214 | | BACKS PACE { 
| | [ | 
{| 215 | | REWIND | 
| | | | 
| 216 | {END FILE | 
| | | | 
| 217 | {WRITE unformatted | 
| | | 
|} 218 | {READ unformatted | 
| | | 
} 219 | {WRITE formatted | 
| | [ | 
| 220 | {READ formatted | 
| | | | 
| 221 | {Beginning of I/0 | 
| | [list | 
| | | | 
| | | | 
| 222 | LDF {Statement number { 
| | | definition | 
| | | | 
| | | 
} 223 {| GLDF |Generated statement | 
| | |number definition | 
| | | 
| | | | 
| 225 | 

L 4 
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|WRITE using NAMELIST 
aL 


| 
J 


(Continued) 


eTable 27. 


Adjective Codes (Continued) 


fe Ooi ae Ain Go re oe ae hapa eds ey ye a 7 


|Code (in| (where 


| 
| 

|decimal) |agplicable) | Meaning 

|-------- {}-------—-- fam nnn nnn nnn 
| 226 | |READ using NAMELIST | 
| | | | 
| 227 | | FIND | 
| | | | 
| 230 | {I/O end-of-file | 
| | | parameter | 
| | | 
| 231 | {I/O error parameter | 
| | | | 
{| 232 | | BLANK | 
| | | | 
{| 233 | RET | RETURN | 
| | | | 
j 234 | STOP | STOP | 
| | | | 
} 235 | | PAUSE | 
| | | | 
|} 238 | | ASSIGN | 
| | | | 
{| 240 | |Beginning of DO | 
| | | 
} 241 | |Arithmetic | 
| { {assignment statement | 
| | | | 
{| 242 | NDOIF [End of DO ‘IF’ | 
| | | | 
| 243 | |Arithmetic IF | 
| | | | 
} 244 | {Relational IF | 
| | | | 
| 246 ] | CALL | 
| | | | 
| 247 | List [I/O or NAMELIST list| 
| [ jitem | 
| | | | 
| 248 | | NAMELIST | 
| | | 
{ 249 | END | END | 
| | | | 
| 250 | |Computed GO TO | 
| | | 
} 251 | |I/O unit number | 
| | | | 
| 252 | |FORMAT (statement | 
| | | numbers) | 
| | | | 
| 253 | | NAMELIST nam | 
bese geese beeper eee ee Roe Dee ey ee J 


Mnemonic 


Examples of Phase 10 Intermediate Text 


An example of each type of phase 10 text (normal, data, namelist, define file format, 
and SF skeleton) is presented below. For each type, a source language statement is first 
given. This is followed by the phase 10 text representation of that statement. 


The phase 10 normal text representation of the arithmetic statement 100 A = B+C * D 
7 © is illustrated in Figure 44. 








ar a PO T Mee ge ee eae Coote eee De ea 1 
| Adjective | | | | | | 
| Code | Chain | Mode | Type | 0 | Pointer | 
|~-----—--~------- {=== }----------------- }~---------- }~---}---------------- { 
| Statement | | | | | | 
| number | | Statement | | | | 
| definition | | number | 0 | | ——* 100 | 
¢----------------- +----------- +----4---------------- { 

| Real | Scalar’ | | ——» A | 

}----------------- +----------- $----}---------------- { 

| Real | Scalar?™ | |——+ B 

+----------------- +----------- +----}---------------- { 

| Real | Scalar’ | |——_e C | 

+----------------- $----------- $----}---------------- { 

| Real | Scalart | {———#m D | 

}------~---------- {----------- }--~--}-----------—---- { 

| Real | Scalar’ | | ——e E | 

$---~-------------- +----------- +----}---------------- { 

To next normal (| | | | | 

text entry | 0 i 0 | | ISN? | 
+~---------------+-}----------- {~-~-}---------------- { 

| | | 1 | | 

| | 2 bytes | 2 bytes |byte| 3 bytes | 
L hse ese SS 8 ee i Oinean oe eee ene ee eh eS | 
| tNonsubscripted variable. | 
| 2Operator of the special text entry that signals the end of the text representation | 
| of a source statement. | 
| 7Compiler generated Sequence number used to identify each source statement. | 
nea ee Oe a MS IOS ee ON et Sere SO SET rr RO ae en tI LITRE aI ee te eee ee See J 


eFigure 44. Phase 10 Normal Text 
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The phase 10 data text representation of the DATA statement DATA A,B/2.1,3HABC/,C,D/1. 
,1./ is illustrated in Figure 45. 3 


CSP e ns oe De i ee re eae yp ee gee 7 aa Raa a ia Ba aa aaa 7 
| Adjective | | | | | | 
{ Code | Chain | Mode | Type } Oo | Pointer | 
} }----------------- $----------- +----}---------------- 
| | | | | To text for | 
| | | | | ——» next DATA fey 
| | 0 | 0 | | statement | 
+ }----------------- +----------- +----}~--------------- { 
| | Real | Scalar | {|—~A | 
+----------------- +----------- 4----}---------------- 
| Real | Scalar | |—+B 
+----------------- ----------- }----}---------------- { 
| Real | Constant | | ——> 2.1 | 
}--~=-------------- +--~-------- +----}---------------- { 
| Literal | Constant | | ——» 3HABC | 
}----------------- t~---------- +----}---------------- { 
| Real | Scalar | |—ecC | 
}----------------- +----------- +~----+---------------- { 
| Real | Scalar | |-——~ D | 
}----------------- {----------- +----{---------------- { 
| Real | Constant | |}——> 1. | 
}----------------- +----------- ----+---------------- { 
| Real | Constant | |— > 1. | 
}----------------- ¢----------- +--~-}---------------- { 
| | [| 1 | | 
| 2 bytes | 2 bytes |byte| 3 bytes | 
Sa ee x a ee dee UO de eo J 





eFigure 45. Phase 10 Data Text 
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The phase 10 namelist text representation of the NAMELIST statement NAMELIST /NAME1/A, 
B,C/NAME2/D,E,F/NAME3/G where A and F are arrays is illustrated in Figure 46. 


aia ale Rares aaa aaa Pe ee ne ee 
| Adjective | 

| Code | Chain 
|~---------------- t~----~-------- 
| NAMELIST | 





NAMELIST | 


NAMELIST 


b= — + — HH HH HH HH HH tt 





®Figure 46. Phase 10 Namelist Text 


a ee ee RD DE GS ee aE SE ee ER GD eee oS eee eee 


a Ne AS EES SAS NS ES ES EE ce NS ee me <TD eee nmin 


fey HH HH HH YH 


a or es 
Type | | Pointer 
~---------- +----4-------------------} 
0 | | ——> NAME1 | 
--~=------- }----}--------------——-~-} 
0 | | To text for | 
|——w next NAMELIST 
| | block | 
~---------- $----4------------------- 
Array | |—eaA | 
----------- }----}-------------------J 
Scalar | |——r B | 
----=------ {~---4~--~--~------------] 
Scalar | |—eC | 
~---------- }----}----~---~----------4 
0 | | ——»> NAME2 | 
~-~-------- {--~-4-------------------4 
0 | | To text for 
| |——» next NAMELIST | 
| | block 
-——-------- {—--+-------------------1 
Scalar | |—> D | 
~~-~------- {----4------------------- 
Scalar | |—r E | 
~---------- t----}-------------------4 
Array | |—, F | 
-~--------- t----4----~--------------| 
0 | —> NAME3 | 
~---------- }~---}-------------------4 
0 | | To text for 
l {|——»next NAMELIST | 
| | statement a 
----------- ----4-------------------] 
Scalar | |——eG | 
---------— }-~--}-------------------4 
| | | 
2 bytes |byte| 3 bytes | 
Bae ee a eee 
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The phase 10 define file text representation of the DEFINE FILE statement DEFINE FILE 
Aq (M4,04,f£4,/V1) where a, is the I/O unit number, m, is the number of records, ry, is the 
maximum record length, f, is the format code, and vq is the associated variable is illus- 
trated in Figure 47. 





fone yo Pee Nes er ra Po ueqe nent rs ee er Mag Cree ete Dre ee ey es 1 
| Adjective | | | | | | 
| Code | Chain | Mode | Type } Oo | Pointer | 
+ + {----------- ¢----+---------------- | 
| | Constant | | ————e a, | 
faa ¢----+---------------- { 
| Constant | | ——_—_—_> IM, | 
$----------- 4----}---------------- { 
{| Constant | | —__—_e r, | 
; + {-----—---- 4----}---------------- { 
format code (£4) | pointer to next | Integer |} Scalar | | —_—_—_> Vv, | 
| | define file text| | { | | 
| | entry | | | | | 
+ {----------- 4----+---------------- { 

| | {| 1 | 
| | 2 bytes |byte| 3 bytes | 
y eee eeeannee semen Se Pree eee ene seam eeneer ens J 





eFigure 47. Phase 10 Define File Text 


The phase 10 format text representation of the FORMAT statement 5 FORMAT (2H0A,A6//5xX, 
3 (14,E12.5,3F12.3,*ABC')) is illustrated in Figure 48. 








ne eee VS ee oe a eae ee aa ae Pe 1 
| Pointer | | | } | | 
| Code | Chain | Mode | Type | O | Pointer | 
|----------------- +----------------- $----------------- }----------- ----}---------------- { 
| Statement { | | | | | 
| number | | Statement | | | | 
| definition | | number | 0 | | 5 | 
4----------------- $----------- 4----4}---------------- { 
| | | | To text for | 

| | | | next FORMAT r 
| FORMAT | | 0 | 0 | | statement | 
: {----------------- }----------- {----}---------------- 1 
| | | 1 | | 
| 2 bytes | 2 bytes |byte| 3 bytes | 
sa ee Ae eS 5 EPs am sew! ouasmerneen Aye yunt atom Seam yuaetneta et 4 
Lessee foe eo ee Pe ee Ae eee ee ee 1 
| //5X 2 { ,3(1 7 |{ | 4,E1 2 | 
~---------------- }~----------------}-----------}--—-}---------------- 
| 3," | aABC' 2 | | ))#? | 
Fae eee ae Ne eR rte ee ee doo a a ee be le += ==] 
1Group mark. | 
| 2One character per byte. | 
ca aa a ae aN aha a ee J 


@Figure 48. Phase 10 Format Text 
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ee 


The phase 10 SF skeleton text representation of the statement function ASF (A,B,C) = 
A+D*¥B*E/C is illustrated in Figure 49. 


ae Lote ean er are Moros ne ee 5 aa aaa Toon Gee ee 1 
| Adjective | | | | | | 
| Code | Chain | Mode | Type {| Oo | Pointer | 
+ + $----------- +----}---------------- { 

| | 9 | | 1 | 

$----------- +----}---------------- { 

| Scalar | Sep | 

{----------- {---~4---------------- { 

| 0 ; i 2 | 

+----------- }----}~--------------- { 

| Scalar | -|—+reE | 

+----------- 4----}---------------- { 

| 0 | | 3 | 

}----------- $----}---------------- { 

[| 9 | | | 

4----------- ¢----+---------------- { 

| 0 | | 0 | 

et fv; 

| 2 bytes {byte| 3 bytes | 

Be ee 5 ae epeaieenns Seay ee a ee NR fer eer era J 





eFigure 49. Phase 10 SF Skeleton Text 
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PHASE 15/PHASE 20 INTERMEDIATE TEXT 
MODIFICATIONS 


During phase 15 and phase 20 text pro- 
cessing, the intermediate text entries are 
modified to a form more suitable for opti- 
mization and object-code generation. The 
intermediate text modifications made by 
each phase are discussed separately in the 
following paragraphs. 


PHASE 15 INTERMEDIATE TEXT MODIFICATIONS 


The intermediate text input to phase 15 
is the intermediate text created by phase 
10. The intermediate text output of phase 
15 is an expanded version of phase 10 
intermediate text. The intermediate text 
output of phase 15 is divided into four 
categories: 


Unchanged text 

Phase 15 data text 
Statement number text 
Standard text 


Unchanged Text 


The unchanged text is the phase 10 
normal text that is not processed by phase 
15. Unchanged text is passed on to subse-* 
quent phases in phase 10 format with but 
one modification: the contents of the 
operator and chain fields are switched. 


Phase 15 Data Text 


To facilitate the assignment of initial 
data values to their associated variables, 
phase 15 converts the phase 10 data text 
for DATA statements to phase 15 data text, 
which is in variable-constant format. The 
format of the phase 15 data text entries is 
illustrated in Figure 50. 


<4 bytes ——____________» 


|field { 

303. °° °° 

ie 

reir eee a 

eer a 

oe. 2a ei 
Entry 


Indicator Field: The indicator field indi- 
cates the characteristics of the initial 
data value (constant) to be assigned to the 
associated variable. This field is one 
byte in length. The indicator field is 
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Chain Field: 


P1 Field: 


P2 Field: 


divided into eight subfields, each of which 
is one bit long. The bits are numbered 
from 0 through 7. Figure 51 indicates the 
function of each subfield in the indicator 
field. 


oe eg ea oe Reg re a ee eee 1 
| Subfield | Function | 
}------------ }---------------------------- { 
| Bit 0 | not used | 
(2 =--Se ee 1 aac eshal alae CARP Rca memeieR alae eee | 
| Bit 1 |} not used | 
|------------ }---------------------------- { 
| Bit 2 | not used | 
}------------ }---------------------------- { 
{| Bit 3 | not used | 
orragr ee aa re Rp raaaTE ne TaeeReE 
} Bit 4 ‘on' | initial data value is nega-| 
| | tive constant | 
|------------ |---------------------------- { 
| Bit 5 ‘on* | initial data value isa | 
| | Hollerith constant | 
}------------ |---------------------------- { 
| Bit 6 fon" | initial data value is in | 
| | hexadecimal form | 
}-~----------- }---------------------------- { 
| Bit 7 ‘on’ | data table entry is six | 
| j words long (variable is an | 
| | array element). | | 
eo alee Md atte a J 
Figure 51. Function of Each Subfield in 


Indicator Field of Phase 15 
Data Text Entry 


The chain field is used to 
maintain linkage between the various phase 
15 data text entries. It contains a point- 
er to the next such entry. 


The P1 field contains a pointer 
to the dictionary entry for the variable to 
which the initial data value is to be 
assigned. 


The P2 field contains a pointer 
to the dictionary entry for the initial 
data value (constant) which is to be 
assigned to the associated variable. 


Offset Field: The offset field contains 
the displacement of the subscripted vari- 
able from the first element in the array 
containing that variable. If the variable 
to which the initial data value is to be 
asSigned is not subscripted, this field 
does not exist. 


Number Field: The number field contains an 
indication of the number of successive 
items to which the initial data value is to 
be assigned. If the initial data value is 
not to be assigned to more than one item, 
this field does not exist. 


Statement Number Text 


The statement number text iS an expanded 


version of the ph 


created for statement numbers. 


expanded to provi 
which statistical 


ase 10 intermediate text 
It is 

de additional fields in 
information about the 


text block associated with the statement 


number is stored. 
number text entri 
Figure 52. 


4 bytes —__________» 


ee ea 
[Chain field 
t i a a a a ies 


|P1 field 


0 qo cow aw ee eee ee ee ee eee eee ores ee ome eee 


|Definition vecto 


|Busy-on-exit 
|vector field (MV 


®Figure 52. 
Entry 


Chain Field: The 
maintain the link 
intermediate text 
pointer to the ne 


Operator Field: 
tains an internal 


for a statement n 
Table 28). 


The format of statement 
es is illustrated in 


ees ee ee ae 1 aia nara aa { 
{Operator |Indicator | 
{field |field | 
ee a ts a Pe eee | 
| 

ss ad ee ee ee | 
| 

Se ee ee | 
(MVF) (4 words) | 
r field (MVS) (4 words) | 
(4 words) | 


X) 


Format of Statement Number Text 


chain field is used to 
age between the various 
entries. It contains a 
xt text entry. 


~~ 


The operator field con- 
operation code (numeric) 
umber definition (see 


eTable 28. 


Phase 15/20 Operators 


ne sae ee BO age ey tae yg ee ees 1 


|Mnemonic 


|Code (in| (where 


|decimal) |applicable) 


OE penne eee a 


10 
11 
12 
13 
14 


15 


16 
17 
18 


19 


fp a Ht 


LA 
EXT 
BG 
BL 


BNE 


BGE 


Appendix B: 


wa 


Load address 


[External function or 


| subroutine CALL 
| 


{Branch greater than 


|Branch less than 


|Branch not equal 


{Branch greater than 


jor equal 


fees comme sume emmee comes SE ems SE ame eee GEES SE eee) ED SEE cee EE SE EEE eS SEED SAEED QRS quuEE auton GED Gee ae ee ee oe SES eee Se ee oe 


(Continued) 


Intermediate: Text 
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eTable 28. Phase 15/20 Operators (Cont.) 

ete arr, Go ee Vo ee 1 
| | Mnemonic | | 
{Code (in| (where | i 
| decimal) |applicable) | Meaning | 
[-------- {----------- +-------------------- { 
| 20 | BLE © {Branch less than or | 
| | {equal : 
| 21 | BE {Branch equal | 
| | | | 
| 22 | SUB | Subscript | 
| | | | 
| 23 | List {I/O list | 
| | | | 
| 24 | BC |Branch computed | 
| | | | 
| 25 | ( | Left parenthesis { 
| | | | 
| 26 } EM {End mark f 
| | | | 
| 27 | B | Branch { 
| | | | 
| 28 {| BA {Branch assigned | 
| | | | 
| 29 | BBT |Branch bit true | 
| | | 
| 30 | BBF {Branch bit false | 
| | | | 
| 31 {| LBIT {Logical value of bit| 
| | | | 
| 32 | BGZ |Branch greater than | 
| { |zero 
| | | | 
| 33 | BLZ {Branch less than | 
| | {zero | 
| | | | 
| 34 | BNEZ |Branch not equal | 
| | | zero | 
| | | | 
| 35 | BGEZ |Branch greater than | 
| | Jor equal zero | 
| | | | 
| 36 | BLEZ {Branch less than or | 
| | {equal zero | 
| | | 
| 37 | BEZ |Branch equal to zero| 
| | | | 
| 39 | NMLS |NAMELIST operands | 
| | | | 
| 4 1 | BF |Branch false | 
| | | 
| 42 | BT |Branch true | 
| | | | 
| 43 | LDB {Load byte | 
| | | | 
| 44 | LIBF |Library function | 
| | [call | 
| | | 
| 45 | RS {Right shift | 
| | | | 
| 46 | Ls | Left shift | 
| | | | 
| 47 | BXHLE {Branch on index ; 
| | 
| 48 | ASSIGN {Assign { 
Ney ae ee Ee eepeed ety seer ea J 

(Continued) 
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| 
| 
\ 
| 
| 
| 
| 
| 
| 
| 
| 
- 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
! 
| 
| 
| 
| 
| 
| 
i 
| 


| routine 


eTable 28. Phase 15/20 Operators (Cont.) 

Carrere, eR a SS SA RG aa aR 1 

|Mnemonic | | 
{Code (in| (where | | 
|decimal) |applicable) | Meaning | 
}------- }----------- }~-----~-------------- 
| 50 | LE |Less than or equal | 
| | | | 
| 51 | GE |Greater than or | 
| | jequal | 
| | | | 
| 52 | EQ | Equal | 
| | | 
| 53 | LT {Less than | 
| | | | 
| 54 | GT {Greater than | 
| | | | 
| 55 {| NE |Not equal | 
| | | 
| 56 | MAX2 |MAX2 in-line routine] 
| | | 
[ 57 | MIN2 {|MIN2 in-line routine| 
| | | | 
| 58 | DIM |DIM in-line routine | 
| | | 
| 59 | IDIM |IDIM in-line routine| 
| | | 
| 60 { DMOD |DMOD in-line routine| 
| | | 
| 61 | MOD |MOD in-line routine | 
| | | 
| 62 |} AMOD {AMOD in-line routine| 
| | | | 
| 63 | DSIGN {|DSIGN in-line | 
| | | routine | 
| | | 
| 64 | SIGN |SIGN in-line routine| 
| | | | 
| 65 | ISIGN | ISIGN in-line l 
| | | routine | 
| | | 
| 66 | DABS |DABS in-line routine| 
| | | 
| 67 | ABS JABS in-line routine | 
| | | 
| 68 | IABS |IABS in-line routine| 
| | | | 
| 69 | IDINT J IDINT in-line | 
| { | routine | 
| | | | 
| 71 | INT | INT in-line routine | 
| | | 
| 72 | HFIX |HFIX in-line routine| 
| | | 
| 73 | <IFIX JIFIX in-line routine| 
| | | | 
| 74 2 | DFLOAT {|DFLOAT in-line | 
| | | routine | 
| | | a | 
| 75 | FLOAT |FLOAT in-line | 
| | | routine | 
| | | 
| 76 | DBLE {|DBLE in-line routine| 
| | | | 
| 77 | BITON |BITON in-line | 
| | | 
u L J 


(Continued) 


eTable 28. 


Phase 15/20 Operators (Cont.) 
aa ae Voge pe Poe ee re oe 1 
| | Mnemonic | | 
{Code (in| (where | | 
|decimal) |applicable) | Meaning | 
}-------- {---=------ +-------------------- { 
| 78 | BITOFF {|BITOFF in-line 
| | | routine 
| | 
| 79 | BITFLP |BITFLP in-line 
| | | routine 
| | | 
| 80 | ANDF |ANDF in-line routine 
| | 
| 81 | ORF {ORF in-line routine 
| | 
| 82 | COMPL {|COMPL in-line 
| | | routine 
| | | 
| 83 } MOD24 }|MOD24 in-line 
| | | routine 
| | 
| 84 { LCOMPL |LCOMPL in-line 
| | |routine 
| | 
| 85 | SHFTR |SHFTR in-line 
| | | routine 
| | 
| 86 | SHFTL |SHFTL in-line 
| | | routine 
| | | 
{| 100 | LR |Load register (phase 
| | [20 only) 
| | 
{| 101 { RC {Restore main storage 
| | | (phase 20 only) 
| | | 
| 102 {| RR |Restore register 
| | | (phase 20 only) 
| | | 
| 103 | {Register usage 
| | | (phase 20 only) 
| | | 
i 104 | {STORE (phase 20 
| | lonly) R13 as operand 
| | | 2 
| | | 
| 193 | {BLOCK DATA 
| | | 
{| 200 | | COMMON 
| | | 
{| 201 { | EQUIVALENCE 
| | 
| 202 | | EXTERNAL 
| | | 
{ 203 | |Register usage 
| | | (phase 20 only) 
| | | 
f 205 | | DATA 
| | | 
| 208 | | FUNCTION 
| | | 
| 209 | | FORMAT 
| | | 
{} 210 | JEND I/O 
bse Us ie pl Pee ne mente ee re eee enna ae 


(Continued) 


[ an ee es |, 


eTable 28. Phase 15/20 Operator (Cont.) 
ere rary Me em regres gee en pee gee aera peg arg ee 1 
| {Mnemonic | | 
|Code (in| (where | : | 
|decimal) |applicable) | Meaning | 
}-------- }---------- ~------------------- { 
| 211 | | CONTINUE | 
| | | | 
| | | . | 
| 212 | {Relative record | 
| [ |number | 
| | | | 
| | _— | | 
| 213 | |Object time FORMAT | 
| | | | 
| | | | 
| 2174 l | BACKSPACE | 
| 7 | | | 
| 215 | | REWIND | 
| | | | 
| 216 | |END FILE | 
| | | | 
| 217 | |WRITE unformatted | 
| | | | 
| 218 | J|READ unformatted | 
| | | | 
| 219 | |WRITE formatted | 
| | | | 
{| 220 | |READ formatted | 
[ | | | 
| 221 | |Begin I/O | 
| | | | 
| 222 | LDF {Statement number | 
| | | definition | 
| | | 
| 223 | GLDF |Generated statement | 
| | Jnumber definition | 
| | | | 
| 224 | | IMPLICIT l 
| | | | 
| 225 l |WRITE using NAMELIST| 
| | | | 
| 226 | |RFAD using NAMELIST | 
| | | | 
| | 227 | | FIND | 
| | | | 
| 230 | {I/O end-of-file | 
1 | |parameter | 
| | | | 
| 231 | |I/O error parameter | 
| | | | 
{| 232 | | BLANK | 
| | | | 
| 233 | RET | RETURN | 
| | | | 
| 234 | STOP | STOP | 
| | | | 
f 235 | | PAUSE | 
| | | | 
| 249 {| END | END 
| | | | 
| 251 | [I/O unit number | 
| | | | 
L «252 | | FORMAT | 
| | | 
| .2523 | | NAMELIST | 
Pagers pees Bip eee OM ae aaa ee ee a 4 
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indicator Field (ABFN): The indicator 
field is one byte long. This field indi- 


cates some of the characteristics of the 
text entries in the associated block. The 
indicator field contains eight subfields, 
each of which is one bit long. The sub- 
fields are numbered 0 through 7. Figure 53 
indicates the function of each subfield in 
the indicator field. 


ep ica saan hr a acca Bg tae ee ee Fe re 1 
| Subfield | Function | 
}------------- }--------------------------- { 
| Bits 0-3 | not used | 
|------------- }--------------------------- { 
{| Bit 4 "ont | associated block contains | 
| | an I/O operation { 
}-------~----- |--------------------------- { 
{| Bit 5 ‘on' | associated block contains | 
| | a reference to a library | 
| function | 
}------------- {--------—------------------ { 
| Bit 6 | not used | 
}------------- }----------------~---------- | 
| Bit 7 ‘on" | associated block contains | 
| | an abnormal function | 
| | reference | 
ee if a ae a er end a ot nn SER ee 4 


Function of Each Subfield in 
Indicator Field of Statement 
Number Text Entry 


®Figure 53. 


P1 Field: The P1 field contains a pointer 
to the statement number/array table entry 
for the statement number. 


BLKEND Field: The BLKEND field contains a 
pointer to the last intermediate text entry 
Within the block. 


Use Vector Field (MVF): The use vector 


field is used to indicate which variables 
and constants are used in the associated 
block. Variables and constants, as they 
are encountered in the module by STALL- 
IEKGST are aSSigned a unique coordinate (1 
bit) in this vector field. In general, if 
the ith bit is on (1), the variable or con- 
Stant assigned to the ith coordinate is 
used in the associated block. 


Definition Vector Field (MVS): The defini- 


tion vector field is used to indicate which 
variables are defined in a block. 

Variables and constants, as they are 
encountered by STALL-IEKGST are assigned a 
unique coordinate (1 bit) in this vector 
field. In general, if the ith bit is on 
(1), the variable assigned to the ith coor- 
dinate is defined in the associated block. 


Busy-On-Exit Vector Field (MVX): The busy- 
on-exit vector field in phase 15 indicates 
which variables are not first used and then 
defined within the text block (not busy-on- 
entry). This field is converted by phase 
20 to busy-on-exit data, which indicates 


which operands are busy-on-exit from the 


144 


®Figure 54, 


block. Variables and constants, as they 
are encountered by STALL-IEKGST are 
assigned a unique coordinate (1 bit) in 
this vector field. In general, during 
phase 15, if the ith bit is on (1), the 
variable assigned to the ith coordinate is 
not kusy-on-entry to the block. During 
phase 20, if the ith bit is on, the vari- 
able or constant assigned to the ith coor- 
dinate is busy-on-exit from the block. 


Standard Text 


The standard text iS an expanded and 
modified form of phase 10 intermediate text 
that is more suitable for optimization. 

The format of standard text entries is 
illustrated in Figure 54. 


| Chain field | 
}--------------------- 1~-------- t--------- { 
{Set by phase 20 {Operator |Mode | 
{Used by phase 25 |field {field | 
[eee ee eee Se Renee See Eee oie a ore ee inno | 
|Set by phase 20 
}Used by phase 25 


|Set by phase 20 
|Used by phase 25 


{Set by phase 20 
{Used by phase 25{| P3 field | 
Pose ee eee sees 4. -_________--------~4 


| Displacement field | 
Format of a Standard Text Entry 


Chain Field: The chain field is used to 
Maintain the linkage between the various 
intermediate text entries. It contains a 
pointer to the next text entry. 


Operator Field: The operator field con- 
tains an internal operation code (numeric) 
that indicates either the nature of the 
statement or the operation to be performed 
(see Table 28). 


P1 Field: The P1 field contains either a 
pointer to the dictionary entry or state- 
ment number/array table entry for operand 1 
of the text entry, or zero (0) if operand 1 
does not exist. 


P2 Field: The P2 field contains either a 
pointer to the dictionary entry for operand 
2 of the text entry or zero (0) if operand 
2 does not exist. 


P3 Field: The P3 field contains either a 
pointer to the dictionary entry for operand 
3 of the text entry, a pointer to a parame- 
ter list in the adcon table, an actual con- 
stant (for shifting operations), or zero 

(0) if operand 3 does not exist. 


Mode Field: The mode field indicates the 
general mode of the expression and the mode 
of the operands. The bits are set by phase 
15. The mode field can be referred to only 
as the fourth byte of the status mode word, 
which consists of a status field (2 bytes), 
an operator field (1 byte), and the mode 
field (1 pyte). The status portion of the 
Status mode word is explained later under 
"PHASE 20 INTERMEDIATE TEXT MODIFICATION," 
The meanings of the bits in the mode field 
are given in Table 29. 


Displacement Field: The displacement field 
appears only for subscript and load address 
text entries; it contains a constant dis- 
placement (if any) computed from constants 
in the subscript expression. 


PHASE 20 INTERMEDIATE TEXT MODIFICATION 


The intermediate text input to phase 20 
is the output text from phase 15. The 
intermediate text output of phase 2U is of 
the same form as the standard text output 
of phase 15. The format of the phase 20 
output text is illustrated in Figure 55. 


Table 29. 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 
| 
| 
| 
a | 


Ri, R2, and R3 Fields: The R1, R2, and R3 
fields (each is 4 bits long) are filled in 
by phase 20 during register assignment, and 
are referred to by phase 25 during the code 
generation process. The assigned registers 
are the operational registers for operand 
1, operand 2, and operand 3, respectively. 


B1, B2, and B3 Fields: The Bl, B2, and B3 
fields (each is 4 bits long) are filled in 
by phase 20 during register assignment, and 
are referred to by phase 25 during the code 
generation process. The assigned registers 
are the base registers for operand 1, 
operand 2, and operand 3, respectively. 


Status Field: The status field, the first 
two bytes of the status mode word, is set 
by phase 20 to indicate the status of the 
operands and the status of the base 
addresses of the operands in a text entry. 
The information in the status field is used 
by phase 25 to determine the machine 
instructions that are to be generated for 
the text entry. The status field bits and 
their meanings are illustrated in Table 30. 


Meanings of Bits in Mode Field of Standard Text Entry Status Mode Word 
Se ree hPa mee Per WOO ed es Ne mn PRT ay ar a te IU eel ee TE z 


| Mode | Bits | Meaning | 
|-----------4--------- }----------------------------------------------------------------- { 
| general | 27-28 [| 00 - Logical | 
| | | 01 - integer | 
| | | 10 - real | 
* }----------- --------- |----------~-------------------------------~----------------------4 
| operand 1] 29 | 0 - short mode (logical*1, integer*2, real*4) | 
| | | 1 - long mode (logical*4, integer, real*8) | 
[----------- t--------- }-------------~----------------------~---------------------------- { 
| operand 2| 30 | 0 - short mode (logical*1, integer*2, real*4) | 
| | | 1 - long mode (logical*4, integer, real*8) | 
|----------- +--------- }---~--------------------------+---+------------------------------- { 
| operand 3j| 31 | O - short mode (logical*1, integer*2, real*4) | 
| | | 1 - long mode (logical*4, integer, real*8) : | 
Oat hte eee het oe a a as a a a J 


~----~--+-------~----------------------- SAEED SuRSSSTEDRRDTEDPoaP >a aREIenten TEREPOEP EPPEPIPIP ieee 
| Status field | Operator field 1 | Mode field ' | 
Pee eee ie ee Ne ee aI Pg ee pg TO Nae fn rer Eee ee a ee | 
| R1 | Bl | Pi field * | 
|---------- 4----------- {---------------------------------------------------------------- { 
| R2 | B2 | P2 field 1 | 
|---------- }----------- }-------------------------------------- === $+ { 
| R3 | B3 | P3 field 1 | 
a 5 See aa ee ee eae a a tN ee | 
| Displacement field' | 
eS a yt ao eg SE ye ee a mee OE SpE a eS ak STP rT TE | 


{*The chain field, mode field, operator field, 


| placement field are as defined in a phase 
| alter these fields.) 


eFigure 55. Format of Phase 20 Text Entry 


15 


P1 field, P2 field, P3 field, and dis- | 
standard text entry. (Phase 20 does not | 
| 
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STANDARD TEXT FORMATS RESULTING FROM PHASES 
15 AND 20 PROCESSING 


The following formats illustrate the 
Standard text entries developed by phase 15 
and phase 20 for the various types of 
Operators. When the fields of the text 
entries differ from the standard defini- 


tions of the fields, the contents of the 
fields are explained. In addition, notes 
tnat explain the types of instructions 


generated by phase 25 are also included to 


the right of the text entry format, when 
appropriate. For an explanation of the 
individual operators see Table 28. 


eTable 30. Status Field Bits and Their Meanings 


(rege et saa aa as aa ae a a A am 7 
| Operand/ | | | 

Base Address | Bit | Meaning | 
}-------------------- +----------- }~-----------~-------------~-+------------------------- | 
| | O=1 | not used | 
| | 2 | 0 - base address in storage | 
| Operand 2 | | 1 - base address in register | 
| base address | | | 
| status | 3 | 0 - do not retain base address in register | 
| | | 1- retain base address in register | 
}~--------~--------—- {---—--—--- fa nnn en nnn { 
| | 4 | 0 - base address in storage | 
| Operand 3 | | 1 - base address in register | 
| base address { | | 
| status | 5 | 0 - do not retain base address in register | 
| | | 1 - retain base address in register | 
[-~------------------ {-----_—--- }----------~-------------------- +--+ ------ =~ { 
| | 6 | 0 - operand in storage | 
{ Operand 2 | | 1 - operand in register | 
| status | | | 
| | 7 | 0 - do not retain operand in register | 
i | | 1 - retain operand in register | 
}-------------------- pnp a a na { 
| | 8 | 0 - operand in storage | 
| Operand 3 | | 1 - operand in register | 
| status | | | 
| | 9 | 0 - do not retain operand in register | 
| | | 1 - retain operand in register | 
}-------------------- +~---------- }-~-~------~------------------------------------------- { 
| | 10 | 0 - base address in storage | 
| Operand 1 | | 1 - base address in register | 
| base address | | | 
| status | 11 | 0 - do not retain base address in register | 
| | | 1 - retain base address in register | 
|~--------~---------- +----------- fanaa -- = a nnn nn nnn { 
| | 12 | 0 - generate store into operand 1 | 
Operand 1 | | 1 - do not generate store into operand 1 | 
status | | | 
|---~---------------- {--~--—----- {------—--------------- +--+ = === $+ === === { 
| | 13 | not used | 
| | 14 | 1 - divide item actually MOD function. If FC=44 | 
| | | or 15, load addresses precede. | 
| | 15 | 1 - .QOXX temporary created for this item | 
a eee Se Tere ne et ey es Rene nN Oy een CN eR ree vad eA Saher ge eee ee J 
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Branch Operator (B) 


le me OS en ee oe 


ase a ana ca S  e e - 
| Chain | 
~~------------------7---------- ---------4 
| Status | Branch | Mode | 
| [operator | | 
pastas tos > oper ee SSS aeS = fesse Sea] 
| RI | jP1 | 
|-----4}-~---}----------------------------- { 
| | | | 
}-----4-----}----------------------------- { 
| | | | 
fase eee A Se ca ee ee | 
| | 
BN eh Fen ees ee a et J 


Logical Branch Operators (BT, BF) 


si a ae ee 


GR gee PTE ge, eg ey eS 1 
| Chain | 
eg ee a : SECA a See AEC 
{| Status | Logical | Mode | 
| | branch | | 
| [operator | | 
|-----y-----7-------- 4—-—-—--—--4------_-- { 
{| R1 | |P1 | 
|-----4-----}----------------------------- { 
{| R2  |B2 | P2 | 
|-----4}-----}----------------------------- { 
| | | | 
bees 2 y eeegeatern a mets a tl aa ee J 


Binary Operators (+, -, *, 7, OR, and AND) 


<—_. 4 bytes ——_—WY________+ 
ge ea ee ee eS 1 
| Chain | 
Sener ape Rg Se ey ee ayy Pe ere ee 
| Status {Binary | Mode | 
| {operator | | 
ees esss pene fee a ee 
} RI {Bl |P1 | 
}--~-- $-----+----------------------------- { 
{| R2 |B2 | P2 | 
————— 4} fn + - = | 


[| R3 [B3  |P3 | 


a I ts 


Pi: The P1 field contains a pointer to the 
Statement number/array table entry for the 
Statement number branched to. 


Note: Phase 25 decides if an RR or an RX 
branch instruction should be generated. 





Pi: The P1 field contains a pointer to the 
statement number/array table entry for the 
Statement number being branched to. 


P2: The P2 field contains a pointer to the 
dictionary entry for the logical variable 
being tested. 


Note: The test of the logical variable 
will be done with a BXH or BXLE for BT and 
BF, respectively. 
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Test and Set Operators (GT, LT, GE, LE, EQ, 
and NE) 


4 bytes —_ 


A Sc a a aa a a ka 1 
| Chain | 
ss eisaiad ates aban ans Foss ss ere 7S SSS 
| Status jTest and | Mode | 
| |set | | 
| {operator | | 
|~----- t-----1-------- 4—-------~- 4-----~-—- { 
{| R71 [Bl [|P1 | 
~---- {--—~--}-~-------~------------------~| 
| R2 |[B2 {P2 | 
|-----}---—- }--~------------------~------- { 
{| R3 |B3 | P3 | 
enone fie reer ae Ma ee eGR al ee ge le A Ne nT PS J 


In-line Functions (MAX2, MIN2, DIM, IDIM, 
DMOD, MOD, AMOD, DSIGN, SIGN, ISIGN, LAND, 
LOR, LCOMPL, IDIM, BITON, BITOFF, AND, OR, 
COMPL, MOD24, SHFTR, and SHFTL) 


ih yt iS ee 


Ce as ee a ee ys eee 7 
| Chain | 
|-------------------- q7--------- --------- { 
{| Status {Function | Mode | 
| {operator | | 
|~----7-----7--------1---------- 1--~--~-—- { 
{| R11 [B11 |P1 | 
[----- +~---- }---~------------------------- { 
| R2 |[B2 | P2 | 
}-----4-----}----------------------------- { 
| R3 |[B3 |P3 | 
|-----4----- }---~------------------------- 
| | | | 
Papen E amen pene ae ay ne tee tn ner re aN eer 4 


Testing a Byte Logical Variable (LDs) 


| Chain | 
date ons asa aca sa ca {ooo eres oon ae 
| Status | LDB | Mode | 
| [operator | | 
aces ais » Seles Sa aa teSaSSseee | 
{| R17 |Bl | | 
----- }-----}-----------------------------] 
| R2 |B2 | | 
|-----}-----}----------------------------- { 
{| R3 |B3 | | 
nee pear ae Sg eee J 
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Note: The LDB operator is used to load a 
register with a byte logical variable. 





Branch on Index Low or Equal, or Branch on 
Index High 


Sige py Pes a ey 


ee a ee ee ee ee 1 

| Chain | 

as Sear eae | cnn eal 1 ican peeea { 

| Status |Add | Mode | 

| |operator | | 
}----~y-----7----1-----—-- t-—----- { 

} R1 | Bl | Pl | 
}-----}-----4--------------------- { 

| R2 | B2 | p2 | Text 
f}——--——— 4-—-—---—+------~--—-—-—--—--—------ 4 Entry 1 
{| R3 | B3 | B3 | 
ere Ms cscs 8 i Glee ee ee ae ee Cea J 


Cee a i ee ee TE he 1 

{| Chain | 
|---------------- -------- y------- { 

| Status |Branch |Mode | 

| [operator | 
|-----y-----7----1-------- 4—-—---- { 

| R11 | | Pl | 
}----- +----- 4--------------------- { 

{| R2 | B2 | P2 | Text 
-}—-———— 4+----~-—+4----—-------—-—--—-—----—-- { Entry 2 
{| R3 | B3 | P3 | 
“Senreanre 1 eeereecees SO ig ee 4 


Computed GO TO Operator 


4 byt es-———___________—_> 


Gee ee TT Pe eee fe a SP eT ee 1 
| Chain { 
Men eG Pere ee een re Fo Se 
| Status {Computed {|Mode | 
| |GO TO | 
| Joperator | | 
}-----7-----7-------- 4-—---—-—~- 1-—-----—— { 
| RI | {P1 | 
}----- }-----}----------------------------- { 
| | P2 | 
|----- $-----4----------------------------- { 
{| R3 | |P3 | 
ene eee y Eee oe A Spa eg Nae ee nk ea oar Pe Oe ere ier wee ae 4 


Note: A BXHLE instruction will ke 
generated by phase 25 when an add operator 
is followed by a branch operator. 





P1 and P2 of text entry 1 equals P2 of 
text entry 2. 


Pi: The P1 field of text entry 2 contains 
a pointer to the statement number/array 
table entry for the statement number being 
branched to. 


Pi: P1 contains the number of items in the 
branch table that are associated with the 
computed GO TO operator. 


P2: P2 contains a pointer to the informa- 
tion table entry for the branch table. 


P3: P3 contains a pointer to the indexing 
value for the computed GO TO statement. 
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Branch Operators 
BG, BLZ, 


(BL, BLE, BE, BNE, BGE, 
BLEZ, BEZ, BNEZ, BGEZ, and BGZ) 


ee eae ee en ET | AR 9g == ee ee 


| Chain | 
foe ae ee ee | cs { 
| Status {Branch | Mode | 
|-----7-----7--------4---------- 4_——~—-——— 
{| R1 |B |P1 | 
}-----+----- }----------------------------- { 
{| R2 {|B2 | P2 | 
|-----}-----}----------------------------- { 
{| R3 [83 |P3 | 
bs y tenner 5 ee ea WA nae RES RTE Cae ce em ete 4 


Binary Shift Operators (RS, LS) 


<——__$_$$_$____—_4 bytes——____________» 


| Chain | 
a Sc | ELA! GUE eae 
| Status |Binary |Mode | 
| |shift | | 
| [operator | | 
oss poses | Sees ene ona ei en { 
{| R1 |81 {P1 | 
}-----}-~---4-------~-------~------------- { 
| R2 |B2 | P2 | 
|-----4----- }----------------------------- { 
| i {Shift quantity | 
eee oaeettn eee aes cn ee i ea ee J 


<.____———-_ 4 bytes a oad 
al a a a 1 
| Chain | 
pRSsSSS Sesser esees = 1 Fea eiae eines 1 panei Seca eae { 
| Status | Load | Mode | 
| jaddress | | 
| {operator | | 
[nae Wao ar tooo eo eae Spa { 
| RI |B1 |P1 | 
|----- {-~-—-4---~--------------- = { 
| R2 |B2 {P1 | 
|~----}-----}----------------------------- { 
{| R3 |B3 | P3 | 
a M Wegener nee Bs ist ee ae cee do ets a 
| Displacement | 
"Hee es tO eon ec te Rt ea ER Dera OTN OY ACE aa 0 ER ET Fe J 
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Pi: The Pi field contains a pointer to the 
statement number/array table entry for the 
Statement number being branched to. 


Note: Operands 2 and 3 must be compared 
before the branch. For the BLZ, BLEZ, BEZ, 
BNEZ, BGEZ, and BGZ operators, operand 3 is 
zero and a test on zero iS generated. 


Note: The purpose of the load address 
operator is to store an address of an ele- 
ment of an array in a parameter list. If 
bit 7 of the status field is 1, the LA 
stores the last argument into the parameter 
list. 


The P1 field points to a dictionary entry 
which points to the adcon table. 


LA (14) is always followed by CALL (15) or 
a library function (44). : 


Subscript Text Entry - Case 1 


4-4 bytes ———____________ » 


poo -- - - - - - - - - - -- - -- - - - - - - - P2: The P2 field contains a pointer to the 


| Chain | dictionary entry for the variable being 
}-——————~————-—-—-—---—-—-—— ~---------- ~--------- 4 indexed. 

| Status {Subscript |Mode | 

| {operator | | 

------ ~----- t-------- 41———_—~—~—~—~—_ 4_—————~—~—_— 4 P3: The P3 field contains a pointer to the 
{| R1 |B }P1 | dictionary entry for the indexing value 
-}-—-—--— +-—-—--- 4-----—-—-—-—~----~—~-—-—-—~----------- | unless the indexing value iS a constant; 

{| R2 |32 |P2 then P3 # 0 and the displacement field con- 
}----—- 4+—--—--- 4—----—-—~-—~----~--~--—-~—-—~—-—-—-~---~—--- { tains a displacement. 

} R3 |B3 | P3 | 

a a eee cae ee | 

| Displacement | 

Cs et ee eee J 

Subscript Text Entry - Case 2 


4 bytes ——_____________ >» 





ah ake i ce a aaa 7 Note: For Case 2 subscript text entries, 
| Chain | the subscript text entry is combined with 
(aaa a eer a ea saan Pana ae : eae ae { the next text entry to form a single RX 

| Status [Subscript |Mode | instruction. (Case 2 will be formed by 

| [operator | | phase 15 only when the second text entry 
pease , ae {=o s=-SS aac oars ae { has the store operator. Phase 20 will 

| | [PI | change Case 1 text entries to Case 2 text 
ope ; Sa I ae { entries when appropriate.) 

Ro. 482 1182 | 

cape ae: ene fae ee ee { P1 is zero and either P2 or P3 of the 
[| R3 [33 |P3 | next text entry will be zero. 

ee Wa rrtae A a eS ee | 

| Displacement } If the operator of the next text entry 


is a store, the subscript applies to Pl. 
If the next operator is not a store, the 
subscript applies to operand = 0. 


If the next operator is a ‘LIST,' the 
subscript applies to P1 for READ or to P2 


for WRITE. 
In-line routines (DABS, ABS, IABS, IDINT, 


INT, HFIX, DFLOAT, FLOAT, DBLE) 


tee ee DY CCS Se eee 


| Chain | 
isis aeRee bac cies mre for ee , i aa { 
{| Status |Operator |Mode | 

arias oe ee ee ee eee 
{| R1 |B1 |P1 | 
|----- 4~----4----------------------------- { 
| R2 |[B2 | P2 | 
|-----}---~-}----------------------------- { 
| | |Not used | 
fist ee E ee een a a a J 


Arpendix B: Intermediate Text 151 


EXT and LIBF Operators 


tip a a al I OS ae eee te 


Gal ant ge eg eee et En The Te ye eee 71 
| Chain | 
[Rae S SSeS eee See Toe | sain esinienaniasiaias | 
| Status {Operator |Mode | 
po===_-S-=s> : ieee oar lea tease SSe== { 
{| R1 | Bl |P1 | 
[----4~------ $----------------------------- { 
{| R2 | B2 | P2 | 
|-—~-f----}--~--------------—----------— { 
| R3 | B3 | P3 | 
agp! Corres eee DG ie a Sia at ice ta ee ns beer ees J 


Arguments for Functions and Calls 


<——$£_—____——________-4 bytes ee 


| Chain | 
ESA Shc a | SR aaT Gane’ Guam aaaLaate 
| Status {Argument |Mode | 
| foperator | | 
|----- 1----- t-------- 4---------- 4-—-----—— { 
| | [P1 | 
|----- aa eS { 
| | [| P2 | 
|-----}-----}----_-----------—------------ { 
| { [P3 (for complex) [ 
bao eee ae i a ae Ne eea ne eA MNO Ae Me aR 4 


Special Argument Text Entry for Complex 
Statements 


NT EES ee Sees ee a S| bytes i eraee oe Oe er ne oe 


(oe ope Te ne Pe ee ee ee re 1 
| Chain | 
PR a ee ES | SERS oAcatal DANES CA 
| Status {Argument |Mode | 
| |operator | | 

pone qo + + 1 + +--+ +--+ --4 
{| R1 [Bt | 
|-----}~----4-------~--------------------- { 
| | | 
|-----}---------------------------------- { 
| | | | 
Ue alasee Seger ewe Ma tS yh a as ta J 
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Pi: P1i1is zero for the EXT operator of a 
subroutine call. 


P2: The P2 field contains either a pointer 
to the dictionary entry for an external 

function or a subroutine name, or a fointer 
to the IFUNTB entry for a library function. 


P3: The P3 field contains either zero or a 
symbolic register number and a displacement 
that fpoints to the okject-time parameter 
list of the external function, library 
function, or subroutine. 


Note: No registers are needed for this 
type of text entry. 


For calis and ABNORMAL functions, P1 = 
P2. For NORMAL functions and library func- 
tions, P1 = 0. 


See the next text entry for the case of 
complex statements. 


Note: For complex statements, the first 
text entry of the argument list contains 
the register information for the imaginary 
part of the complex result. 


Assigned GO TO Operator (BA) 


<4 bytes ——____________» 


Go ae ee ee ees ee ee 1 
| Chain | 
a a aa ae a tooo 
{| Status {Assigned |Mode | 
| {GO TO | | 
| {operator | | 
o> | nena : ian aes SSeS Ss saa cae { 
| | | | 
|-----}-----}--------~-------------------- { 
{| R2  |[B2 {P2 | 
[----- 4-----4----------------------------- { 
| | | | 
Ci p Rasen fea se CaN ep amen eee ER eh eae Pe ee ea ee J 


READ/WRITE Operators for I/O lists 


READ 


Le ee ea ee i ee eee 7 
| Chain | 
eee eo ee ae ee eee 
| Status | READ | Mode | 
| Joperator | | 
SSeS qe a a eee 
| R1 Bl {P1 | 
|----- f-----}+---------------------------- { 
| | | | 
[-----}-----}---~--------~--------~------- { 
| | | P3 | 
emewer pe ence BU ag a ar ae Se J 
WRITE 


a aaa a 1 
| Chain | 
Ses SaaS | CEe Seaway SURG EE 
| Status |WRITE | Mode | 
| joperator | | 
}-----y-----7-------- 4---------- 4—---—---- { 
| R1 {Bl | | 
|-----4-----}~---------------------------- { 
| | | P2 | 
|-----+----- ~---------------------------- { 
| | | P3 | 
iaec22 eee reese a SRN eS SNe a Re Pe ea ne pT a J 


P2: The P2 field contains a pointer to the 
variable being used in the assigned GO TC 
statement. 


Pi: The P1 field contains a pointer to the 
I/O list for the READ statement. If this 
is an indexed ‘READ, R1 is the register to 
be used. 


Note: If the P3 field contains a zero, an 
entire array iS being read. This causes a 
different instruction Sequence to he 
generated. 


P2: The P2 field contains a pointer to the 
I/O list for the WRITE statement. R1 and 
B1 are the index and base registers to be 
used for the WRITE. 


Note: If the P3 field contains a zero, an 
entire array is being written. This causes 
a different instruction sequence to ke 
generated. 
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Logical Branch Operators (BBT, BBF) 


-—____—_————_-4 bytes ————_____________» 


| Chain | 
eg eg rege ee ee ic at Lo { 
| Status | Logical | Mode | 
| | Branch | | 
| joperator | | 
}----- .-----1-------- 41—-------~- 1--------- { 
; R11 | | P1 | 
|----- }-----4----------------------------- { 
| {B2 | P2 | 
|-----+-----+----------—------—----------- { 
| | [| P3 | 
ane ae : ee eee SLSR ae ee es ere ya ee nC aes te ol Pee eA er J 


| Chain | 
}-------------------- q---------- qo-------- 
{| Status {| LBIT | Mode | 
| {operator | | 
fs=5 oe ee scene iia Sa ae a | 
{| R1 |B1 |P1 | 
|-----4-----4----------------------------- { 
|B2 | P2 | 
}----- 4-----}----------------------------- { 
| | | P3 | 
eee eed cone eee tee i ha ea eine J 
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Pi: The Pi field contains a pointer to the 
statement number/array table entry for the 
statement number being branched to. 


P2: The P2 field contains a pointer to the 


dictionary entry for the logical variable 
keing tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 


P2: The P2 field contains a pcinter to the 
dictionary entry for the logical variable 
being tested. 


P3: The P3 field contains a pointer to the 
dictionary entry for the number of the bit 
being tested. 


The major arrays of the compiler are the 
bit strip and skeleton arrays, which are 
used by phase 25 during code generation. 
The following figures illustrate the bit 
Strip and skeleton arrays associated with 
the operators of text entries that undergo 
code generation. The Skeleton array for 
each operator iS illustrated by a series of 
assembly language instructions, consisting 
Of a baSic operation code, which is modi- 
fied to suit the mode of the operands, and 
operands, which are in coded form. The 
operand codes and their meanings are as 
follows: 


Bn--base register for operand n 


BD--base register used for loading an 
operand's kase address 


Rn--cperational register for operand n 
&--index register when necessary 


To the right of the skeleton array for 
an Operator is’ the bit strip array for the 
operator. Each bit strip in the bit strip 
array consists of a vertical string of O's, 
1's, and X's. A particular strip is 
selected according to the status informa- 
tion, which is shown above that Strip. For 
exampie, if the combined status of operands 
2 and 3 is 1010 (reading downward), the bit 
Strip below that status is to be used dur- 
ing code generation. (The status of 
operand 2 is indicated in the first two. 
vertical positions, reading downward; the 
Status of operand 3 is indicated in the 
second two vertical positions, reading 
downward’). The meanings of the various 
bit settings in each bit strip are as 
follows: 


O0--The associated skeleton array 
instruction is not to be included 
aS part of the machine code 
sequence. If a horizontal line 
containing all zeros appears after 
an inStruction in a skeleton, zero 
may be changed to a one to perform 
the desired function. This typic- 
ally happens for base register 
loads and result stores. 


1--The associated skeleton array 
instruction iS to be included as 
part of the machine code sequence. 


1In some cases, operand 3 does not exist 
and only the status of operand 2 is 
indicated. 


A 
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X--The associated skeleton instruc- 


tion may or may 


not ke included as 


part of the machine code sequence, 
depending upon whether or not the 


associated base 
loaded, 
into operand 1 i 


address is to be 


or whether or nct a store 


s to be performed. 


IEKVPL: Used for All Subtract Operations 
oo Ta re ee ee ee Me ae en 1 
| | Skeleton | | 
| Index | Instructions | Status | 
|-----4------—-------—--— }—~-~~-—-—--—--~- { 
| | {|0000000011111111| 
| | |0000111100001111 | 
| | |0011001100110011| 
[ | |0101010101010101| 
| | | 
| 1 |L B2,D (0,BD) | XXXXXXXX00000000] 
| 2 |LH R2,D (0,B2) {0000111100000000 | 
; 3 JH R1,D (X, B2) | 1100000000000000 | 
| 4 |L B3,D (0,BD) | XXOOXXO0OXX00XX00 | 
| 5 |LCR R3,R3 |0010001000000010 | 
| 6 |LR R1,R2 | 0000110100001101| 
| 7 {LH R3,D (0,B3) {|0100010001000100 | 
{| 8 |LCR R1,R3 {|0001000000000000 | 
| 9 {SH R1,D (X,B3) | 1000100010001000 | 
! 10 {SR R1,R3 {0100010101110101| 
| 171 |AH R3,D (X,B2) |0010000000000000| 
|} 12 {AH R1,D (X,B2) {0001000000000000 | 
| 13  |AR R3,R2 |0000001000000010| 
| 14 |L B1,D (0,BD) | XXXXXXXXXXXXXXXxX | 
{ 15 {STH R1,D(0,B1) | XXXXXXXXXXXXXXXxX | 
eer A afta 5 ah se Date po eres one sees J 
| IEKVTS: Used for the INT, IDINT, IFIX, and 

HFIX In-Line Routines 

ans Fp gaa ee Ye ey 1 
| | | INT, | 
| | | IFIx, | 
| | Skeleton {| HFIX IDINT | 
| Index| Instructions | Status Status | 
fo3ss= fase ep eo aa Fas mei a masa oe { 
| | | 0011 0011 | 
| | | 0101 0101 | 
| | | | 
} 1 #|SDR 0,0 { 1111 0000 | 
{} 2 {LL B2,D (0, BD) | XxX00 XX00_~ | 
| 3 |LD R2,D (0,B2) {| 0100 0100 | 
|} 4 |LD 0,D(0,B2) {| 1000 1000 | 
| 5 {LDR 0O,R2 | 0111 0111 | 
| 6 |AW 0,60 (0, 12) { 1111 1111 | 
| 7 |STD 0,64 (0,13) { 1111 1111 | 
| 8 |L R1,68 (0, 13) { 1111 1711 | 
| 9 |BALR 15,0 | 1111 Tit. 
{ 10 |BC 10,6 (0, 15) | 1111 11117 | 
| 11 |LNR R1,R1 {| 1111 11171 | 
f 12 |L B1,D (0,BD) | XXXX XXXX_ | 
| 13 |STH R1,D(0,B1) | XXXX XXXxX_ | 
Sa re eee NER RES: CNSR RA NR eee Bee ea ee ARE my RE J 
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| IEKVAD: Used for the ABS, 
In-Line Routines 

aie maar Po ee ee 
| { Skeleton 
| Index | Instructions 
}--------- {~------------------- 
| [ 
| | 
| | 
| 1 | L B2,D (0, BD) 
| Z {| LH R2,D (0,B2) 
| 3 {| LPR R1,R2 
4 | L B1,D(0,BD) 
| 5 | STH R1,D (0,B1) 
ee ene Ee ass tee ee ee 


IABS and DABS 


ee ce ee ee ee ee ee ee ee 


ee Ae ED NS AOS eS RD ERED <ee eee 


be nese emee EE ee GE ae mes awe anes 


| IEKVFP: Used for the MOD24 In-Line Routine 


fone an = oS ee ee Nae 71 
| Skeleton | | 

| Index | Instructions {| Status | 
(a= 4----~---------——--—— 1 aa aaa { 

| | | 0011 | 

| | | 0101 

| | | | 

| 1 | ooL B2,D(0,BD) | Xx00 | 

| 2 | R2,D (X,B2) | 1100 | 

| 3 | LA R1,0 (0,R2) | 1111 | 

| 4 | B1,D(0,BD) | MEX | 

| 5 |. Sf R1,D (0,B1) | XXXX | 

Ua eee eee bl See nen ser a Oe eR re Ree i emer pele Ane a terat es J 

| IEKVTS: Used for the MAX2 and MIN2 In-Line 

Routines 

Oa eee gp eg Wee org ere 1 

| Skeleton | | 

| Index Instructions | Status | 
Sh ete ee 


|0000000011111111| 
|0000111100001111] 
10011001100110011] 


| 

! 

| {0101010101010101| 
| | | 
| 1 L B2,D (0, BD) | XXXXXXXX00000000| 
| 2 LH R2,D(0,B2) |0000111100000000 | 
{| 3 LH R1,D(0,B2) {1 1100000000000000 | 
| 4 |CR  R1,R2 {0000001000000010| 
{| 5 |CH  R3,D(0,B2) |0001000000000000| 
| 6 |CH  R1,D(0,B2) |0010000000000000| 
| 7 |[L B3,D (0, BD) | Xx0OXX00XX00Xx00 | 
| 8 |LH R3,D(0,B3) {0100010001000100| 
| 9 {CR  R2,R3 {0100010101110101| 
| 10 |CH R2,D(0,B3) |0000100000001000 | 
{| 11 |CH  R1,D(0,B3) | 1000000010000000] 
{| 12 |LR  R1,R2 | 0000110100001101| 
| 13 {LR R1,R3 |0001000000000000| 
| 14 |BALR 15,0 {(11411111111111111| 
| 15 |BC N,6(0,15)1 [1111119117111111] 
| 16 |LR  R1,R2 | 0000001000000010 | 
| 17 |~LR  R1,R3 |0100010101110101] 
{| 18 |LH R1,D(0,B2) {0011000000000000| 
| 19 |LH R1,D(0,8B3) | 1000100010001000 | 
} 20 {L B1,D (0, BD) | XXXXXXXXXXXXXXxXxX| 
{| 21 {STH R1,D(0,B1) | XXXXXXXXXXXXXXxXxX| 
+ meee aepers hp tS ips ae al a ae aes Sl a i aN a a A ee { 


|[1For MAX2,N=2; 


for MIN2,N=4. | 


| IEKVFP: Used for the SHFTR and SHFTL In- 
Line Routines 

Cee Se er ee et ee ee ee gt er eee eee 1 
| | Skeleton | | 
| Index | Instructions | Status | 
enone a ana ac : Seale ace iaiato IR 
| | {|0000000011111111| 
| | |0000111100001111| 
| | 10011001100110011| 
| | {0101010101010101 | 
| | | | 
| 1 |L B2,D(0,BD) | XXXXXXXX00000000 | 
} 2 |L. R2,D2 (X,B2) {| 1171111100000000]| 
} 3 {LR R1,R2 |0000111100001111| 
| 4 |L B3,D (0, BD) | XXOOXXOOXX00XX00 | 
} 5 |LH R3,D3 (X,B3) |1100110011001100| 
{| 6 {SRL R1,0(0,R3) }7117117111111111111] 
{| 7 |L B1,D (0, BD) | XXXXXXXXXXXXXXXxX| 
| 8 {ST  R1,D(0,B1) | XXXXXXXXXXXXXXXX| 
Serene 5 ci ee OER ee en ee eR g See ee ee a A ee eras J 

| IEKVACL: Used for the DBLE In-Line Routines 
[Ss 25o Vee a a oe 1 
| | Skeleton | 
| Index | Instructions {| Status | 
Porkensea7 a aac ci rc 2 nein goa antRtam asia { 
| | | 0011 | 
| | | 0101 | 
| | | | 
| 1 | B2,D (0,BD) | XX00 | 
| 2 | SDR R1,R1 | 1111 | 
| 3 | LER 0,R2 | 0010 | 
| 4 | LE R1,D (0,B2) | 1100 | 
| 5 | LER R2,R1 | 0100 | 
| 6 | LDR R1,0 | 0010 | 
| 7 | LER R1,R2 | 0001 | 
| 8 | L B1,D (0,BL) | XXXX | 
| s) | STD R1,D(0,B1) | XXXX | 
eae een aya he ee ee ae De Ponte as J 

| IEKVIS: Used for DIM and IDIM In-Line 

Routines 

(or =7 > Perea a ee Toe er 1 
| | Skeleton | | 
| Index| Instructions | Status | 
(===<= sca ae ace S usetassienues at ea aria nna onia 
| | {0000000011111111] 
| | {0000111100001111] 
| | |0011001100110011] 
| | 1|0101010101010101] 
| | | 
| 1 |L B2,D (0,BD) | XXXXXXXX00000000 | 
| 2 |LH R2,D (0,B2) {0000111100000000 | 
{| 3 |LH R1,D (0,B2) | 1101000000000000 | 
| 4 |LCR R1,R3 |0010001000000010 | 
| 5 {AH R1,D (0,B2) |0010000000000000| 
| 6 |L B3,D (0,BD) | XXOOXX00XX00XX00 | 
{| 7 |LH R3,D (0,83) |0100010001000100 | 
| 8 {LR R1,R2 |0000110100001101 | 
| 9 |SH R1,D (0, B3) | 1000100010001000 | 
| 10 |AR R1,R2 |0000001000000010| 
| 11 |SR R1,R3 {0101010101110101| 
{! 12 |BALR 15,0 }11711111191111111] 
{| 13 |BC 10,6 (0,15) 111117111111111111] 
| 14 |SR R1,R1 | 11771111711111117111] 
} 15 IL B1,D (0,BD) | XXXXXXXXXXXXXXxXxX | 
| 16 {STH R1,D(0,B1) | XXXXXXXXXXXXXXXxX | 
ee eee [Gee ieee etal Ser Os Ba ear eee 5 aera unr ak, Meare 


| TLEKVTS: Used for SIGN, ISIGN, and DSIGN 
In-Line Routines 

por ys Pera oa ee ape Oe Me ee See 1 
| | Skeleton | | 
| Index | Instructions | Status | 
}-----~ }------------------ $~--~------------ 
| | {|0000000011111111]| 
| | {0000111100001111] 
| | |0011001100110011| 
| | {|0101010101010101| 
| | | 
| 1 |L B2,D (0, BD) | XXXXXXXX00000000 | 
{ 2 {LH R2,D (0,B2) |0000111100000000| 
{| 3 |LTR R3,R3 |0010001000100010| 
{} 4 |LH R1,D (0,B2) |1111000000000000]| 
{| 5 |L B3,D (0, 8D) | XXxOOXXO00XX00XX00 | 
| 6 |LH R3,D (0,83) |0100010001000100| 
; 7 |LR R1,R2 |0000001000000010| 
| 8 {LPR R1,R2 |0000110100001101| 
| 9 {LPR R1,R1 |1101000011010000| 
{| 10 |LTR R3,R3 {0101010101010101] 
{ 11 |TM 128,D (0, B3) | 1000100010001000 | 
{ 12 |BALR 15,0 | 1711711711111111111] 
{ 13 {BC 14,6 (0,15) | 1000100010001000| 
{, 74 |BC 10,6 (0,15) |0111011101110111| 
{ 15 |LNR- R1,R1 [11771111711117111111] 
} 16 {BC 15,12 (0,15) |0010001000100010] 
| 17 |LPR R1,R1 {0010001000100010| 
| 18 [L B1,D (0, 8D) | XXXXXXXXXXXXXXXX| 
| 19 |STH R1,D(0,B1) | XXXXXXXXXXXXXXXxX | 
eee ac Sy aea se se eee J 

| IEKVAD: Used for DMOD and AMOD In-Line 

Routines 

amas ee oe ee ete ee Bop egy ee 71 
| | Skeleton | | 
j Index | Instructions | Status | 
|-----4------------------ +---------------- 
| | {0000000011111111| 
| re |0000111100001111| 
| | {0011001100110011]| 
| | {(0101010101010101| 
| | | | 
{} 1 |L B2,D (0,3D) | XXXXXXXX00000000] 
| 2 |LD R2,D (0,B2) |0000111100000000 | 
{| 3 |LD Rly). (0,B2) |1111000000000000| 
— {STD R1,Temp' |done by IEKVAD | 
| 4 |L B3,D (0,8BD) | XXOOXXOOXX00XX00 | 
| 5 {LD R3,D (0,383) {0100010001000100| 
| 6 |LDR R1,R2 |0000111111111111] 
| 7 {DDR R1,R3 |011101110117110111| 
| 8 |DD R1,D (0,B3) | 1000100010001000| 
{| 9 |AD R1,n (0,12) [177171711711111111] 
{| 10 |MDR- R1,R3 {0111011101110111]| 
{ 11 |MD R1,D (0,B3) | 1000100010001000| 
{| 12  |LCDR R1,R1 {1171111111111111] 
| 13 {AD R1,D(0,B2)* |1111111100000000| 
| 14 |ADR R1,R2 |0000000011111111] 
f 15 |L B1,D (0, BD) | XXXXXXXXXXXXXXXxX | 
| 16 {STD R1,D(0,B1) | XXXXXXXXXXXXXX XX | 
|-~---}---------~------~-}---------------- { 
|*When the statuses and base address sta- | 
| tuses of operands 2 and 3 are zero, a | 
| store of operand 2 into a temporary will| 
| be done as indicated and the add will be| 
| from the temporary location. | 
a a J 


| 


| IFKVAD: Used for COMPL and LCCMFL In-Line 
Routines 
Sess a aa era a aa aa 1 
| Skeleton | 
| Index | Instructions | Status | 
}--------- $----~--------------- +---------- { 
| | | 0011 | 
| | | 0101 | 
| | | 0000 | 
| | | 0000 | 
| | | | 
1 | LL B2,D(0,BD) | XX00 | 
| 2 | R2,D (0,B2) | 0100 | 
| 3 | LA R1,1 (0,0) | 1101 | 
| 4 {| LCR R1,R1 | 1111 | 
| 5 | xX R1,D2(X,B2) | 1000 | 
| 6 | XR R1,R2 | 0101 | 
| as {| BCTR R1,0 | 0010 | 
| 8 | .L B1,D (0,BD) | XXXX | 
| 9 | ST R1,D(0,B1) | XXXX 
ea eee Oe ee ae ee By oases ieee J 
| IEKVUN: Used for NOT Operations 
ina ararie saat errs ee ae ee ee ee Rn ere ee 1 
| | Skeleton | | 
{| Index | Instructions {| Status | 
}--------- 4-------------------- ---------- 
| | | 0011 | 
| | | 0101 | 
| | | | 
| 1 | -L B2,D (0, BD) | XX00 | 
| 2 | LA R1,1 (0,0) | 1101 | 
| 3 | BCTR R1,0 | 0010 | 
| 4 {| LCR R1,R1 | 0010 | 
| 3. | xX R1,D (X,B2) | 1000 | 
| 6 | L R2,D2(0,B2) | 0100 | 
| 7 {| XR R1,R2 | 0101 | 
| 8 | L B1,D (0, BD) XAXARX | 
| 9 | ST R1,D (0,B1) | XXXX | 
ah ee tac a SO oe eine J 
| IEKVBL: Used for All Branch True and 
Branch False Crperations 
(er eS Mee ge eee Me ee ee i 1 
| | Skeleton | | 
| Index | Instructions | Status | 
|-----}-~--------------- 4----------------- { 
| | {|0000000011111111 | 
| | |0000111100001111 | 
| | {[0011001100110011 | 
| | 10101010101010101 | 
| | | | 
| 1 {LL B2,D(0,8D) | OOO0D0Q000O000DONN | 
|} 2 |L R2,D (0,B2) |1111111700000000 | 
{ 3 JSR R3,R3 |1100110011001100 | 
| 4 {L B1,D(0,BD) {1177117717111111111 | 
{| 5 |BXH R2,0(R3,B1) {1171171717111111111*] 
| 6 |BXLE R2,0(R3,B1) |1111111111111111*| 
}~----+----------------- $----------------- { 
|*One of these two instructions will be 
jadded to the bit strip by subroutine 
|MAINGN-IEKTA depending on the orferation. 
aces re Rete mn ee ary Me Nine ee ee es Pee 4 
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| IEKVUN: Used for All Load Address 
Operations 
raat Tee ere ae ee Meee gg ee ee 1 
| | Skeleton | | 
| Index| Instructions | Status | 
|-----4------------------ +-~----~--------- { 
| | {|0000000011111111] 
| {0000111100001111] 
| | {0011001100110011| 
| | {0101010101010101| 
| | | 
{| 1 {L B3,D (0, BD) |0O000000000000000| 
| 2 |LH R3,D (0, B3) | 1100110011001100| 
} 3 [4 B2,D (0, BD) {| 0000000000000000 | 
| 4 |LA R1,D (R3,B2) {1111111111111111] 
| 5 |[L D (0, BD) | 0000000000000000 | 
| 6 [ST R1,D (0,831) {| 111117111111111111| 
| 7 |LA 0,128 (0,0) |0000000000000000| 
|} 8 |MVI 128,D (0,81) eee eco 
Bee Nn eset ea 
| IEKVUN: Used for All Load byte Operations 
eae Ne pe ee ee Go ee ee 7 
| | Skeleton | | 
| Index | Instructions | Status | 
|-----4------------------ +---------------- { 
| | {0000000011111111] 
| | }0000111100001111| 
| | {0011001100110011] 
| | {[0101010101010101] 
| | | 
} 1 |[L B3,D (0, 8D) {0000000000000000| 
{| 2 |SR R3,R3 | 1111111100000000 | 
| 3 |aic R3,D (X, B3) (111111111171111111] 
| 4 {[L B1,D (0, BD) | 0000000000000000| 
{; 5 |[ST R3,D (0,B1) oe 
eae 5 OR Seae a een ne alee ee Seen (anette ester eek anata Pate 
| IEKVPL: Used for all Half-Word Integer 
Division Operations and for the 
MOD In-Line Routine 
oe a et ee ee ee rey 
| { Skeleton | | 
| Index | Instructions Status | 
}-----4------------------ 4---------------- { 
| | |0000000011111111| 
| {0000111100001111] 
| | }0011001100110011| 
| | }0101010101010101| 
| | | | 
| 1 |L B2,D (0, BD) | OOOO000000000000| 
| 2 |LH R2,D (0, B2) | 0000111100000000 | 
| 3 |LH R1,D (0, B2) | 1111000000000000}] 
} 4  |L B3,D (0, BD) {0000000000000000| 
| 5 | R3,D (X, B3) | 1100110011001100] 
| 6 |LR R1,R2 }0000111100001111] 
{| 7 |SRDA R1,32 (0,0) {711711119111711111111] 
| 8 |DR R1,R3 1 1111117111111111| 
{| 9 |D R1,D (X, B3) |0000000000000000| 
{| 10 |L B1,D (0, BD) |} 0000000000000000 | 
{| 11 |STH R1+1,D(0,B1) |0000000000000000] 
| 12 |STH R1,D(0,B1)* |0000000000000000| 
}-----4~------------------}---------------- { 


| IEKVSU: Used for Case 1 and Case 2 Suk- 
script Operations 
es Pree en ee ia a 1 
j | Skeleton | | 
eee Instructions | Status | 
}-----4---------~------—~ 4—-----------~~-- : 
| Case 1 | 
}-----7~-----------------y---------------- 
| | }0000000011111111] 
| | {0000111100001111 | 
| | 10011001100110011]| 
— | {0101010101010101 | 
}-----}------------------ 4---------------- { 
{| 1 |L B3,D (0,BD) | 0000000000000000| 
{| 2 |LH R3,D (0,B3) | 1100110000000000 | 
|} 3 |L B2,D (0,BD) | 0000000000000000 | 
} 4 |LH R2,D (0,B2) {1111111100000000| 
|} 5 |[L B1,D(0,BD) |0000000000000000 | 
} 6 |STH R2,D(0,B1) eeceeeovegoer es 
}~---—1---~----~-—-------4------_-__----- { 
| Case 2 | 
|-----7-~----------------7---------------- { 
| | 10000000011111111| 
| | |0000111100001111 | 
| | |0011001100110011 | 
| | }0101010101010101| 
}----- }------------------}~---------------- 
} 1 |[L B3,D (0,BD) |0000000000000000 | 
| 2 |LH R3,D (0,B3) | 1100110011001100| 
| 3 |L B2,D (0,BD) |0000000000000000] 
| 4 |LH R2,D (0,B2) |0000000000000000 | 
} 5S |L B1,D(0,BD) {| 0000000000000000| 
{| 6 |STH R2,D(0,B1) | ee 
baa2s5 We ae Be 
| IEKVUN: Used for All Unary Minus 
Cperations 
ars A se a aa 5 a is a a aa as lac 1 
| | Skeleton | | 
| Index | Instructions [ Status { 
[---—- fanaa en ee mein }---~—---—----——-- 
| | |0000000011111111 | 
| | |0000111100001111| 
| | {0011001100110011 | 
| | |0101010101010101 | 
| | | 
} 1 |[L B2,D (0,BD) |0000000000000000 | 
|} 2 {LH R2,D2 (X,B2) {1111111100000000 | 
|} 3 [LCR R1,R2 {171711119711111717111] 
; 4 |L D (0, BD) |0000000000000000 | 
|} 5 |STH R1,D1 (X,B1) Sa piscine tees ch aaa 
ean Ba a ea ee 
| IEKVBL: Used for All Assigned GC TO 
Cperations 
Peer ee eet a a ea Tae te ee nl 
7 Skeleton | | 
| Index | Instructions { Status | 
}-----}-~---------—------ +-----~--------~- { 
| | {|0000000011111111] 
| { {0000111100001111| 
| | |0011001100110011 | 
| | {0101010101010101| 
| | | : | 
{ 1 {[L B2,D (0,BD) |0000000000000000 | 
} 2 |L R2,D (0,B2) |1111111100000000| 
| 3 |BCR 15,R2 aceite: 
bit Dena ni eee ee SME ee ee [fee Secaet ene ony ee mE 


| IEKVBL: Used for All Computed GC TO 
Operations 
[cas aa gan reece ee 1 
| | Skeleton | | 
{Index| Instructions | Status | 
paSa== pee ee ee fe ae = 
| | |0000000011111111] 
| | {0000111100001111] 
| | {0011001100110011] 
| | {0101010101010101] 
| | | | 
{ 1 |L B3,D (0, BD) | 0000000000000000 | 
| 2 |L R3,D3 (0, B3) | 1100110011001100] 
| 3 |LR R1,R3 {0101010101010101| 
{| 4 |LA R2,P1 (0,0) }11117111711111111] 
| 5 |CLR R1,R2 1 7711111111111111] 
| 6 |BALR R2,0 [1171111111111111] 
{| 7 |SLL R1,2 (0,0) {1177117111111111111f 
| 8 |BC 2,14 (0,R2) 117117111117111111] 
| 9 {[L R2,D (R1,B) {171111171111111111] 
| 10 |BCR 15,R2 ee ee 
eee Hn OO a Re ee Re ee Beene Pe res eee i ea aa 
| LEKVSU: Used for All Store Operations 
(aaa Re ey eS Se ne Det ery tome See 1 
| | Skeleton | 
| Index | Instructions | Status | 
|-----}------------------ ---------------- 
| | |0000000011111111] 
| | |0000111100001111| 
| | {0011001100110011] 
; | |0101010101010101] 
| | | 
} 1 |[L B2,D (0, BD) | 0000000000000000 | 
} 2 |LH R2,D (0, B2) |} 1111111100001000| 
| 3 |L B1,D (0, BD) |O0O00000000000000] 
{| 4 |STH R2,D (X,B1) eo sana naenpauas niger 
beso Doe Nae st eee tee Me a 
| IEKVTS: Used for the FLOAT and DFLOAT In- 
Line Routines 
ae a Mt Pere Ce i Wee ae ot 1 
| | Skeleton { | 
| Index jf Instructions j Status | 
}-------—- {-------------------- +---------- { 
| | | 0011 | 
| | | 0101 4 
| | | | 
| 1 | .- B2,D (0,BD) | XX00 | 
| 2 {| LH R2,D (0,B2) | 1100 | 
] 3 {| LD R1,60(0,12) | 1111 | 
| 4 | STD R1,72(0,13) | 1111 | 
| 5 | LTR R2,R2 | 1111 | 
| 6 | BALR- 15,0 | 1111 | 
= 7 | BC 4, 16 (0, 15) | 1111 | 
8 | st R2,76(0,13) | 1111 | 
| 9 {| AD R1,72 (0,13) | 1111 | 
| 10 {| BC 15,26(0,15) | 1111 ; 
| 11 | LPR 0,R2 | 1111 | 
| 12 | st 0, 76 (0, 13) | 1111 | 
| 13 {| SD R1,72(0,13) | 1111 | 
| 14 | L B1,D(0,BD) | XXXX | 
| 15 | STD D(O,B1) |  XXXxX~ | 
Ran ee ene Cae eee el eet oan ee eee ore ie BS sete 4 


ed, Point Multipli- 
S 


4 
| 0000000011111111] 
{0000111100001111] 
{0011001100110011] 
{0101010101010101] 


| 
10000000000000000] 
|0000111100000000| 
1 1100000000000000} 
10000000000000000] 
10100010001000100| 
|0000110100001101] 
| 0001000000000000| 
{0100010101110101} 
|0000001000000010| 
| 1000100010001000} 
| 0011000000000000] 
10000000000000000| 
|.0000000000000000| 


Se arene pe a a hcp aS al a a a al a a ee ae ae 


| IEKVPL: Used for All Fix 
cation Operation 
‘ec aae Yo eS ea 
| | Skeleton 
| Index| Instructions 
|-----}------------------ 
| | 
| | 
| | 
| | 
| | 
| 1 [LZ B2,D (0, BD) 
| 2 |LH R2,D (0,B2) 
| 3 |LH  R1,D(X,B2) 
} 4 {[L B3,D (0,BD) 
| 5 {LH  R3,D(0,B3) 
{| 6 {LR R1,R2 
| 7 |LR  R1,R3 
| 8 |MR Ri=1,R83 
| 9 |MR R1-1,R2 
| 10 |MH  R1,D (X,B3) 
1 11  |MH D (X,B2) 
{ 12 |L B1,D (0,BD) 
| 13 {STH R1,D(0,B1) 
| IEKVAD: Used for the AND 
Routines 
ces sm ae 
| | Skeleton 
| Index | Instructions 
|-----4------------------ 
| | 
| | 
| | 
| | 
| | 
| 1 | L B2,D(0,BD) 
| 2 |L R1,D (X,B2) 
[ 3 |L B3,D (0, BD) 
| 4 |N R1,D (X,B3) 
| 5 |[L aaa 
| 6 |ST D (0,B1) 
Pace Open er ai igen edo 
| IEKVSU: Used for All Rig 
Cperations 
euaranaiss ei Se Ca a aah 
| | Skeleton 
| Index | Instructions 
|-----+------------------ 
| | 
| | 
| | 
| | 
| | 
| 1 |[L B2,D (0,BD) 
| 2 |LH R2,D (0,B2) 
{| 3 |LR R1,R2 
| 4 |SRA_ R1,P3 (0,0) 
| 5 |HDR R1,R2 
| 6 |L B1,D (0,BD) 
| 7 |STH R1,D(0,B1) 


Appendix C: 


and OR In-Line 


|0000000011111111] 
10000111100001111] 
10011001100110011} 
10101010101010101] 


| | 
| 0000000000000000} 
11111111111111111] 
| 0000000000000000| 
11191111111111111] 
| 0000000000000000| 
ee 


ht- and Left-Shift 


|0000000011111111| 
10000111100001111] 
10011001100110011] 
10101010101010101| 


| | 
| 0000000000000000] 
11111111100000000| 
|0000111100001111| 
111711111111111111] 
| 0000000000000000| 
{0000000000000000| 
| 0000000000000000| 
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| IEKVPL: Used for all Full-Word Integer 
Division Operations and for the 
MOD In-Line Routine 

iar Lt Se ee ee oe 7 
{ | Skeleton | 

| Index| Instructions | Status | 
|----- +-----------------—- +---------------- { 
| | |0000000011111111| 
| | |0000111106001111]| 
| | |0011001100110011| 
| | {0101010101010101| 
| | | 
| 1 |L B2,D (0, BD) | 0000000000000000 | 
| 2 |LH R2,D (0, B2) |0000111100000000| 
| 3 |LH R1,D (0,B2) | 1111000000000000 | 
} 4 |L B3,D (0, BD) |0000000000000000| 
| 5 |LH R3,D (X, B3) |0100010001000100| 
{| 6 |LR R1,R2 | 0000111100001111f 
{| 7 |SRDA R1,32 (0,0) {111111171117111111] 
{| 8 |DR R1,R3 {01110711101110111] 
| 9 |D R1,D (X, B3) | 1000100010001000| 
| 10 |L B1,D (0, BD) | 0000000000000000 | 
| 11 4.|STH ee {0000000000000000| 
| 12 ae D(0,B1) * Lceeeaecatadauna ies: 
}~----4~--------------~--1---------------- { 
|* For aoe in-line ee only. | 
Ne a cS ee 4 

| LEKVTS: Used to Compare Operands Across a 


Relational Operator and Set the 


Result to True or False 

areas pee ee Sr gr rey 1 
{ | Skeleton | 

| Index | Instructions | Status | 
|~~--- 4--~-----~--------- {----~----------- { 
| | |0000000011111111| 
| | |0000111100001111| 
| | {0011001100110011] 
| | |0101010101010101| 
| | | | 
| 1 |[L B2,D (0, BD) | 0000000000000000 | 
{| 2 |LH R2,D (X, B2) 11111111100000000| 
| 3 |L B3,D (0, BD) {| 0000000000000000 | 
| 4 |LH R3,D (0, B3) |0100010001000100| 
| 5 {CH R2,D (X, B3) | 100010001000 1000 | 
| 6 |CR R2,R3 {0111011101110111] 
| 7 |LA R1,1 (0,0) }711111111711111111] 
| 8 |BALR 15,0 ,1711711111171171111111] 
| 9 {BC M,6 (0,15) {111177111171111111] 
| 10 |SR R1,R1 117171111111111111| 
{} 17 |[L B1,D (0, BD) | 0000000000000000 | 
{ 12 |ST R1,D (0,B1) er 
Cee i Cae eee een ere hoe neen eee ae 5 iach ee eee ee 


| IEKVUN: Used for All Logical Operations 
Gene Fe ere ort Se 1 
| | Skeleton | 
| Index | Instructions | Status | 
passe saa mare aa) Saar MGR FUL SECT 
i | |0000000011111111] 
| | |0000111100001111] 
| | {|0011001100110011] 
| | {0101010101010101 | 
| | | | 
| 1 [L B2,D (0,BD) {0000000000000000| 
| 2 f{L R2,D (0,B2) |0000111100000000 | 
|; 3 |{L R1,D2 (0,B2) |1101000000000000 } 
f 4 {L B3,D (0,BD) |0000000000000000 | 
; 5 |L R3,D (0,B3) |0100010001000100| 
|} 6 |[L R1,D3 (X,B3) |0000100000001000 | 
| 7 {LR R1,R2 |0000010100000101 | 
|; 8 |NR R1,R2 |0000101000001010| 
|} 9 |NR R1,R3 {0101010101110101] 
} 10 |N R1,D2 (0,82) |0010000000000000| 
} 11 |N R1,D3 (X,B3) | 1000000010000000 | 
| 12 |L D (0, BD) |0000000000000000 | 
| 13 {ST R1,D1(0,B1) ee ee 
Seaneenre is f Giana pee eae ane ween RAT ATS Nk ae ene er Rie Se Me eae ene 

| IEKVPL: Used for All Addition Cferations 

and for Real Multiplication and 
Division Operations 

(=> ig ee Me eg en ee 1 
| | Skeleton | 
| Index | Instructions | Status | 
}-----4------------------ 4---------------- { 
| | {0000000011111111| 
| | |0000111100001111] 
| | }0011001100110011| 
| | |0101010101010101| 
| | | | 
} 1 |[L B2,D (0, BD) |0000000000000000 | 
| 2 |LH R2,D (0,B2) {| 0000111100000000| 
| 3 |LH 1,D (X,B2) |1101000000000000 | 
} 4 |L B3,D (0, BD) |0000000000000000 | 
| 5 |LH R3,D (0,B3) |0100010001000100] 
| 6 |LH R1,D (X,B3) {0000000000000000 | 
| 7 |LR R1,R2 |0000110100001101] 
| 8 |AR R1,R2 | 0000000000000000 | 
{| 9 |AR R1,R3 {0101010101110101]| 
| 10 |AH R1,D (X,B2) |0010000000000000 | 
| 11  |AH R1,D (X,B3) | 1000100010001000 | 
{, 12 {[L D (0, BD) {0000000000000000| 
{| 13 |STH R1,D(0,B1) | Nea antaneae ue selon ciagel 
p=aSe OO aE a a 
{Note: For real ne wt tee and divi- 


j|sion operations, the basic operation 
|codes will be replaced by the required 


ie Orees 


| TLEKVBL: Used for Text Entries Whose Opera- | IEKVBL: Used for Text Entries Whose Opera- 
tor is a Relational Operator tor is a Relational Cperator 
Operating on Two Nonzero Operands Operating on One Operand and Zero 


ica i a a a laa Teas tes sos a 1 (oSsS= Te ae wr, ee er Rg ep ee ee 1 
| | Skeleton | | | Skeleton | | 
| Index | Instructions | Status | | Index| Instructions | Status | 
foe ep ern er to | ees qr eG ee er ee Te et | 
| | {|0000000011111111] | | |0000000011111111| 
| | |0000111100001111] | | |0000111100001111| 
| | {|0011001100110011] | | |0011001100110011 | 
| | 10101010101010101] | | {0101010101010101] 
| | | | | | | 
; 1 |L B2,D (0, BD) |0000000000000000 | | 1 |L B2,D (0, BD) | 0000000000000000 | 
|} 2 |LH R2,D (0,B2) }1111111100000000]| {| 2 |LH R2,D (0,B2) {1111111100000000 | 
| 3 {L B3,D (0, BD) | 0000000000000000 | } 3 |[L B3,D (0, BD) | OCOO0000000000000 | 
| 4 {LH R3,D (X, B3) 10100010001000100| | 4 |LH R3,D (X,B3) {|0000000000000000 | 
} 5 |CH R2,D (X, B3) | 1000100010001000| | 5 |CH R2,D (X,B3) | OOO0000000000000 | 
} © |CR R2,k3 {0111011101110111] | 6 |CR R2,R3 | DOO0D00D0D000 000000] 
| 7 |LTR R2,R2 | 0000000000000000| | 7 |JLTR R2,R2 {1171111117111111| 
; 8 {[L R1,P1 {17717171111111117] | 8 |[L R1,P1 {171717111111111111] 
} 9 |BCR M,R1 {17171111711171111111] |} 9 |BCR M,R1 {171117171117111111117111] 
annem a cee Pee se ce NS ata re erie oe ae One aye een 4 ics teas es ra Saree ae ee a aes Bh ar as Tere soa ee J 
| IEKVFP: Used for the LBIT, BBT, and BBF In-Line Routines 
(oo fos ee ee Bp ere ee eee epee ee re Va ee ee ae 1 
| | l BBT ,BBF { | LBIT 
| | |------------~--------------}}-------------------------- { 
| | Skeleton | simple Sukscripted |] simple sukscripted | 
{| Index | Instructions | variable variable || variable variable | 
|------- }~---------------------- foa--=----=-- === -- === ----- +}-------------------------- { 
| 1 | L B2,D (0, BD) | X X 1 | X X | 
| 2 | LA 15,D+N/8 (X,B2) | 0 1 || 0 1 | 
| 3 ; TM M,D+N/8 (B2) | 1 0 | | 1 0 | 
| u | TM M,0 (15) | 0 1 || 0 1 | 
| 5 | TM M,D+N/8 (R2) | 0 0 || 0 0 | 
| 6 | L 15,P1 | 1 1 | | 0 0 | 
| 7 | BCR MM, 15 | 1 1 1 | 0 0 | 
| 8 | BALR 15,0 | 0 0 || 1 1 | 
| 9 | LA R1,1 (0,0) | 0 0 1 | 1 1 | 
| 10 | BC 1,10 (0, 15) | 0 0 | | 1 1 | 
| 11 | SR R1,R1 | 0 0 | | 1 1 | 
{ 12 | L B1,D (0, BD) | 0 0 | | X X | 
|} 13 | oF R1,D(0,B1) | 0 0 | | X X 
mere ee epee ee ee re ee ah sch ss eke ey Sea ne | 
| N = The bit to be loaded or tested. | 
| | 
| | M = MSKTBL (MOD (N,8) +1). MSKTBL iS an array of masks used by IEKVFP. { 
| | 
| MM = 1 FOR BBT. | 
| 
| MM = 8 FOR BBF. | 
Ee ea ee ERO a ee) SN Mr ORO PC Sky NS We RCN oS NEUE PRC EEO eae STE TEN erg aa RSDP AW FU el tp aL OS eT OS Le TT J 
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APPENDIX D: TEXT OPTIMIZATION EXAMPLES 


This appendix contains examples that illustrate the effects of text optimization on 


Sample text entry Sequences. An example is presented for each of the five sections of 
text optimization. 


Example 1: Common Expression Elimination 


This example illustrates the concept of common expression elimination. The text 
entries in block A are to undergo cormon expression elimination. Block B is a kack 
dominator of block A. Block B contains text entries that are common to those in block A. 


(1) (2) (3) 
Block B 


Unchanged Unchanged 


Eliminate 
T8 =J * 12 


————— 


Eliminate 


T7=1%*4 


—— $$ 


Block A 


T7=1*4 
T8=J* 12 
T9 = 17 + T8 
T10 = X (s T9 
B=TI0+Z 


T8 =J* 12 
T9=T1+T8 
T10 = X (s T9 
B=T10+Z 


19 =T1+T2 
T10 =X (s T9 
B=T10+Z 





, te @ 28 e 






Unchanged Unchanged 
Eliminate Eliminate 
T9=T1+ 712 T10 = X (§ T3 
————_$$ 


A 


T10 = X (s T3 
B=TI0+Z 





NOTE: The items Ti are temporaries and (s represents a subscript operator 
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Example 2: Backward Movement 


This example illustrates both methods of ktackward movement. The text entries in 
block A are to undergo backward movement. Block EF is the back target of the loop 


containing block A. 


(1) (2) 
Block B 






Move Move 
TI=A+B T2=T1I+C 
a 
X=E+U 
T2=TI+C 
E=12+D 
(3) (4) 
Move the 
expression 
™2+D 





NOTE: The text entry X = E + U cannot be moved, because its operand 2 is 
defined elsewhere in the loop. The text entry E = 12 + D cannot be 
moved, because operand | (E) is busy-on-exit from the back target; 
however, the expression T2 + D can be moved. 
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Example 3: Simple-Store Eliminatson 


The following example illustrates the concept of simple-store elimination, an 
integral part of the processing of backward movement. 


Eliminate Z = X 


+B 
ae. 
*M 
JA 


<N7NX' | 
NXO>P: > 
HOoUs th a 

5 oe 


"Ne e+ 


va 
A 
D 
X 
Z 


How tk ud 


REINO 





— oe ee oe ee ee ee ee ee ee ee eee ee ee oy 


SE A LTD ET NE RD ED ATE RD TTS NORD RNS ED LENS ET ED A A OED <A GE GES A OE ET EE TY AS ED A RD AEE CUES ERE EE EET RD ORNED CURED EES emt SE ERD ES ARS GED CREE CUD CED NED END QUE ED ERED QUES SOD RD EEE SE ED SE ED ED RE EE ED EE EUS RE EET TERE Se cee aE ESN <OENED <ETED GEENP UD UAE ete IND we ee tm 


{| Note: Uses of operand 1 of the simple store that appear below the redefinition of 
| either operand of the simple store are not replaced. 
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Example 4: Strength Reduction 


This example illustrates both methods of strength reduction. 


strength reduction is applied to a DO loop. 


In the example, 


The evolution of the text entries that 


represent the DO loop, and the functions of these text entries are also shown. The 


formats of the text entries in all cases are not exact. 


manner to facilitate understanding. 
Consider the DO loop: 


I=3 
DO 10 J=1,3 
A=X (1,9) 

10 CONTINUE 


They are presented in this 


As a result of the processing of phases 10 and 15, and kackward movement, the DO loor 
has been converted to the following text representation. 


Initializes J 
Back 
Target 


T1 =1I* 4 |Multiplies first 


[by its dimension 


a A EO CINE REN AoE EEO ARE OORT GEG SE Ge SR ame se 






|subscript parameter 


}Stated in source module, converted to | 
[ehase 10 text and then to phase 15 text. | 
| It resided in the kack target of the | 
| loog because of text blocking. | 
| | 
|Generated phase 10 text entry, converted | 
[to phase 15 text entry. It resided in the| 
|back target of the loop because of text | 
|blocking. | 
| 
| 
| 
| 
| 
| 


{Generated by phase 15 when it encounters 
lthe subscript parameter I during its pro- 
|cessing of phase 10 text. It resides in 


| factor {the krack target of the loop as a result 

| Jof the processing of backward movement. 
~---~----------- {o-oo 
Y T2 = 3 * 12 |Multiplies second |Generated by phase 15 when it encounters | 
| |subscript parameter |the subscript parameter J during its pro-| 
| Jby its dimension {cessing of phase 10 text. | 
| | factor. | | 
| | 
| T3 = T1 + T2 |Computes index value|Generated by phase 15 after the last sub-| 
| |for the sukscripted |Script parameter in the phase 10 text | 
{ |variable xX. [representation of the subscripted vari- | 
| | fakle has been processed. | 
| | | 
Loop | A= X (s T3 |Stores X(I,J) into A|The rphase 10 text entry forced and con- (| 
| | |verted to phase 15 text after the index | 
| | |value for the subscripted variakle has | 
| | [been established. | 
| | | 
[ JI=J+ 1 | Increments DC index.|Generated by chase 10 and converted to | 
| | [phase 15 text representation. | 
| | | 
| IF (J2=3) GOTO Y|Tests DO index {Generated by phase 10 and converted to | 
| jagainst its maximum |phase 15 text representation. | 
| {and controls branch-| | 
Jing. | | 
ba ase alk a cae tates J ee = | 


| Note: 


4) . 


The statement number Y is generated by phase 10. 
{that the array X is of the form X (3,3) and that its elements are real 
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Also, it is assumed | 
(length | 
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The following figure illustrates the application of strength reduction to the loop. 


q) 2 — ®) 






Eliminate 
Additive 
Text from Loop 


Eliminate 
Multiplicative 
Text from Loop 






Y12=)%]2 
T3 = T1 + T2 
A =X (s T3 
J=jJ+1 
IF SS 3) GOTOY 


YT3=TI+M 
A=X (6713 
M=M+12 
IF (MS 36) GOTOY 


YA=X (sP 
P=P+12 
IF (PSN) GOTOY 
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This appendix describes the logic of 
some of the object-time library subprograms 
that may be referenced by the FORTRAN load 
module. Included at the end of this appen- 
dix are flowcharts that descrike the logic 
of the subprograms. 


Each object module, compiled from a FOR- 
TRAN source module, must be processed Ly 
the linkage editor prior to execution on 
the IBM System/360. The linkage editor 
must combine certain FORTRAN library sub- 
programs with the object module to form an 
executable load module. The library sub- 
programs exist as separate load modules on 
the FORTRAN system library (SYS1.FORTLIB). 
Each library subprogram that is externally 
referred to by the object module is 
included in the load module by the linkage 
editor. Among the library subprograms that 
may be so referred to are: 


® ITHCFCOMH 
ment processor) 


(object-time I/O source state- 
- entry name IBCOM#. 


e IHCFIOSH (object-time sequential access 
I/O data management interface) - entry 
name FIOCS#. 


e IHCNAMEL (object-time namelist rou- 
tines) - entry names FRDNL# and FWRNL# 


e IHCDIOSH (object-time direct access I/0 
data management interface) - entry name 
DIOCS#. 


e IHCIBERH (object-time source statement 
error processor) - entry name IBERH#. 


e IHCFCVTH (object-time conversion rou- 
tine) - entry name ADCCN#. 


e IHCDBUG1 (object-time Debug Facility 
Support routine) - entry name DEBUG#. 


e ITHCTRCH (object-time terminal error 
message and diagnostic traceback rou- 
tine) - entry name IHCTRCH. 


e IHCADST 
ment routine) 


(object-time boundary adjust- 
- entry name IHCADJST. 


IHCFCOMH receives I/O requests from the 
FORTRAN load module via compiler-generated 


1The FORTRAN IV (H) compiler does not have 
the code generation facilities for DEBUG 
Statements. The discussion is included 
because the FORTRAN G compiler (which does 
include DEBUG) and the FORTRAN H compiler 
share a common library. 
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OBJECT-TIME LIBRARY SUBPROGRAMS 


calling sequences. IHCFCOMH, in turn, sub- 
mits these requests to the appropriate data 
management interface (IHCFIOSH or 
ITHCDIOSH) . 


IHCFIOSH receives sequential access 
input/output requests from IHCFCCMH and, in 
turn, submits those requests to the appro- 
priate BSAM (basSic sequential access 
method) routines for execution. 


IHCDICSH receives direct access input/ 
outrut requests from IHCFCCMH and, in turn, 
Ssukmits those requests to the arrropriate 
BDAM (basic direct access method) routines 
for execution. 


If source statement errors are detected 
during compilation, the compiler generates 
a calling sequence to the IHCIBERH subpro- 
gram. IHCIRERH processes okject-time 
errors resulting from improperly coded 
source statements. IHCFCVTH contains the 
various okject time conversion routines 
required by IHCFCOMH and IHCNAMEL. ICHTRCH 
processes terminal object-time error mes- 
Sages and produces a diagnostic traceback 
for IHCFCCMH. ICHADJST processes object 
time specification exceptions if the boun- 
dary alignment option is specified by the 
user during system generation. 


ITHCFCOMH 


IHCFCOMH performs object-time implemen- 
tation of the following FORTRAN source 
Statements. 


READ and WRITE (for sequential I/O). 


e READ, FIND, and WRITE 
access I/OQ). 


(for direct 


e RACKSPACE, REWIND, and ENDFILE 
tial I/O device manipulation). 


(sequen- 


e STOP and PAUSE (write-to-operator). 

In addition, IHCFCOMH: (1) processes 
object-time errors detected by various FCR- 
TRAN library subprograms, (2) processes 
arithmetic-type program interruptions, and 
(3) terminates load module execution. 


Ali linkages from the load module to 
IHCFCOMH are compiler generated. Each time 
one of the above-mentioned source state- 
ments is encountered during compilation, 
the appropriate calling sequence to IHCF- 
COMH is generated and is included as part 
of the okject module. At okject-time, 
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these calling sequenceS are executed, and 
control is passed to IHCFCOMH to perform 
the specified operation. 


Note: IHCFCOMH itself does not perform the 
actual reading from or writing onto data 
sets. It submits regquests for such opera- 
tions to the appropriate I/O data manage- 
ment interface (IHCFIOSH or IHCDIOSH). The 
I/O interface, in turn, interprets and sub- 
mits the requests to the appropriate access 
method (BSAM or BDAM) routines for execu- 
tion. Figure 56 illustrates the relation- 
Ship between IHCFCOMH and the I/O data 
Management interfaces. 





Charts 23, 24, and 25 illustrate the 
overall logic and the relationship among 
the routines of IHCFCOMH. Table 36, the 
IHCFCOMH routine directory, lists tne rou- 
tines used in IHCFCOMH and their functions. 


| FORTRAN | 
{| Load | 
| Module | 
rer 
| 
| 
I/O | 
Request | 
| 
Sapa sa ese sae Enea aaa 1 
| IHCFCOMH | | IHCFCVTH | 
| (Determine |{--—4Conversion| 
{Request type) | | Routines | 
eee At ee J 
| 
Submit | | Submit 
Sequential | | Direct 
Access I/0 | | Access I/0 
Request to | | Request to 
ITHCFIOSH | | IHCDIOSH 
| | 
| | 
ere ners een enrene! Cree pote eee 
| THCFIOSH | | IHCDIOSH | 
| (Sequential | (Direct | 
| Access I/O | | Access I/O | 
| Interface) | | Interface) | 
Liste eee: neatnte J (eee ead 
| | 
| | 
Interpret | | Interpret 
And submit | | And submit 
Request to _ | } Request to 
Appropriate | | Appropriate 
BSAM Routine | | BSAM/BDAM 
| | Routine 
| | 
peee eee oS eee eee pao ----—5 
| BSAM | | BSAM/BDAM | 
| Routines | | Routines | 
ete es J ee See 
Figure 56. Relationship Between IHCFCCMH 


and I/O Data Management 
Interfaces 
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The routines of IHCFCOMH are divided 
into the foilowing categories: 


Read/write routines. 

I/O device manipulation routines. 
Write-to-orperator routines. 
Utility routines. 


The read/write routines implement both 
the sequential I/O statements (READ and 
WRITE) and the direct access I/C staterents 
(READ, FIND, and WRITE). (The direct 
access FIND statement is treated as a READ 
statement without format and list.) 


The I/C device manipulation routines 
implement the BACKSPACE, REWIND, and END 
FILE source statements for sequential data 
sets. These statements are ignored for 
direct access data sets. 


The write-to-operator routines implement 
the STOP and PAUSE source Staterents. 


The utility routines: (1) process 
errors detected by FORTRAN library subpro- 
grams, (2) process arithmetic-tyre program 
interrupts, and (3) terminate load module 
execution. 


READ/WRITE ROUTINES 


The READ/WRITE routines of IHCFCOMH 
implement the various types of READ/WRITE 
statements of the FORTRAN IV language. For 
Simplicity, the discussion of these rou- 
tines is divided into two parts: 


e READ/WRITE statements not using 
NAMFLIST. 


e READ/WRITE statements using NAMELIST. 
READ/WRITE Statements Not Using NAMELIST 


For the implementation of koth sequen- 
tial and direct access READ and WRITE 
statements, the read/write routines of 
ITHCFCOMH consist of the following three 
sections: 


e An opening section, which initializes 
data sets for reading and writing. 

e An I/C list section, which transfers 
data from an input buffer to the I/O 
list items or from the I/O list items 
to an output buffer. 

e A closing section, which terminates the 
I/O operation. 


Within the discussion of each section, a 
read/write operation is treated in one of 
two ways: 


e As a read/write requiring a format. 
e As a read/write not requiring a format. 


Note: In the following discussion, the 
term “read operation" implies both the 
sequential access READ statement and the 
direct access READ and FIND statements. 

The term “write operation" implies both the 
sequential access WRITE statement and the 
direct access WRITE statement. 





OPENING SECTION: The compiler generates a 
calling sequence to one of four entry 
points in the opening section of IHCFCOMH 
each time it encounters a READ or WRITE 
statement in the FORTRAN source module. 
These entry points correspond to the opera- 
tions of read or write, requiring or not 
requiring a format. 


Read/Write Requiring a Format: If the 
operation is a read requiring a format, the 


opening section passes control to the 
appropriate I/O data management interface 
to initialize the unit number specified in 
the READ statement for reading. (The unit 
number is passed, aS an argument, to the 
opening section via the calling sequence.) 
The I/O interface: (1) opens the data con- 
trol block (via the OPEN macro instruction) 
for the specified data set if it was not 
previously opened, and (2) reads a record 
(via the READ macro instruction) containing 
data for the I/O list items into an I/C 
buffer that was obtained when the data con- 
trol block was opened. The I/O interface 
then returns control to the opening section 
of IHCFCOMH. The address of the buffer and 
the length of the record read are passed to 
IHCFCOMH by the I/O interface. These 
values are saved for the I/O list section 
of IHCFCOMH. The opening section then 
passes control to a portion of IHCFCOMH 
that scans the FORMAT statement specified 
in the READ statement. (The address of the 
FORMAT statement iS passed, aS an argument, 
to the opening section via the calling 


sequence.) The first format code (either a 
control or conversion type) is then 
obtained. 


For control type codes (e.g., an H for- 
mat code or a group count), an I/O list 
item is not reguired. Control passes to 
the routine associated with the control 
code under consideration to perform the 
indicated operation. Control then returns 
to the scan portion, and the next format 
code is obtained. This process is repeated 
until either the end of the FORMAT state- 
ment or the first conversion code is 
encountered. 


For conversion type codes (e.g., an I 
format code), an I/O list item is required. 
Upon the first encounter of a conversion 
code in the scan of the FORMAT statement, 
the opening section completes its proces- 
Sing of a read requiring a format and 
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Read/Write Requiring a Format: 


returns control to the next sequential 
instruction within the load module. 


The action taken by IHCFCOMH when the 
various format codes are encountered is 
illustrated in Table 31. 


If the operation is a write requiring a 
format, the opening section passes control 
to the I/C interface to initialize the unit 
number specified in the WRITE statement for 
writing. (The unit number is passed, as an 
argument, to the opening section via the 
calling sequence.) The I/O interface opens 
the data control block (via the CPEN macro 
instruction) for the specified data set if 
it was not previously opened. The I/0 
interface then returns control to the open- 
ing section of IHCFCOMH. The address of an 
I/C buffer that was obtained when the data 
control Elock was opened is saved for the 
I/O list section of IHCFCOMH. Subsequent 
opening section processing, Starting with 
the scan of the FORMAT statement, is the 
Same as that described for a read requiring 
a format. 


Read/Write Not Requiring a Format: If the 
cperation iS a read or write not requiring 


a format, the opening section processing 
except for the scan of the FORMAT statement 
is the same as that described for a read or 
write requiring a format. (For a read or 
write not requiring a format, there is no 
FCRMAT statement.) 


I/C LIST SECTICN: The compiler generates a 
calling sequence to one of four entry 
points in the I/0 list section of IHCFCCMH 
each time it encounters an I/C list item 
associated with the READ or WRITE statement 
under consideration. These entry points 
correspond to a variable or an array list 
item for a read and write, requiring or not 
requiring a format. The I/C list section 
performs the actual transfer of data from: 
(1) an input buffer to the list items if a 
READ statement is being implemented, or (2) 
the list items to an output Luffer if a 
WRITE statenent is being implemented. In 
the case of a read or write requiring a 
format, the data must be converted before 
it is transferred. 


In proces- 
Sing a list item for a read requiring a 
format, the I/O list section passes control 
to the conversion routine associated with 
the conversion code for the list item. 
(The appropriate conversion routine is 
determined by the portion of IHCFCOMH that 
scans the FORMAT statement associated with 
the READ statement. The selecticn of the 
conversion routine depends on the conver- 
Sion code of the list item being 
processed.) 
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Table 31. IHCFCOMH FORMAT Code Processing 


| 
| FORMAT Code 


Ee re ee re ee eee i Soe ge eer i Fg ee a ego ne eee ee Po ee Ge ore een or eo ee eae ere 7 
|Description |Type |Corresponding Action Upon Code by IHCFCOMH | 
| | | | 

Sec ke a Thee ee ee : 
[beginning of control {Save location for possikle repetiticn of the 
| statement |format codes; clear counters. 


3 


=) 
i, 


bj 
ra 


3 
ms 


‘text' or nH 


ce ce me 
e 
Qs Qs Os 


HO iy 
Zaz =z 


Qs 


NE OD 
fezz= 


Pe ee ee ee re ee eee eee ee eee eee ee See ee eee ee 
\ 
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free mee rns ee are eer cen ce ee ce ce Em ee eS ES Re SE nN NN Re A SS RL mR NN RO ON a SS A eS ND en ne me 
NEO PHO HY 


group count control {Save n and location of left parenthesis for 
{possible repetition of the format codes in the 
| group. 
| 

field count control [Save n for repetition of format code which 
| follows. 


scaling factor|control 


| 
| 
| | 
| | 
column reset |control {Reset current position within record to nth 
| {column cr byte. 
| | 
| | 
Skip or blank [control |Skip n characters of an input record or insert n 
| [blanks in an output record. 
| | 
| | 
literal data J|control [Move n characters from an input reccrd to the 
| 
| 
| 


group end 


record end 


end of 
statement 


| 
+ 
| 
| 
| | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 


Save n for use by F, E, and D conversicns. 


|FORMAT statement, or n characters from the 
{FORMAT statement to an output record. 
| | 
conversion|conversion|Exit to the load module to return control to 
conversion|conversion|entries FICLF or FIOAF in IHCFCVTH. Using in- 
conversion|conversion|formation passed to the I/C list section, the| 
conversion|conversion|address and length of the current list item are | 
conversion|conversion|obtained and passed to the proper conversicn| 
conversion|conversion|routine together with the current position in| 
conversion|conversion|the I/C kuffer, the scale factor, and the values| 
conversion|conversion|of wandd. Upon return from the conversion | 
| {routine the current field count is tested. If| 
|it is greater than 1, another exit is made to| 
|the load module to obtain the address of the 
[next list item. | 
| | 
| | 


| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


control |Test grour count. If greater than 1, repeat] 
|format codes in group; otherwise continue to| 
[process FORMAT statement from current rosition. | 


| 
| 
| 
| 
| 
| 
| 
| 
| | 
| | 
{control {Input or output one record via I/C Interface| 
| land READ/WRITE macro instruction. | 
| | : | 
| | 
| 
| 
| 
| 
| 
| 
L 


control {If no I/C list items remain to ke transmitted, | 
|return control to the load module to link to the} 
{closing section; if list items remain, input or| 
foutput one record using I/O interface and READ/| 
|WRITE macro instruction. Repeat format ccdes| 


|from last parenthesis. | 
SL pre ee tes ester Farad eat a ete een ee DR END ne SAC eee ere OE eT Ey ma are ree 


The selected conversion routine obtains 
data from an input buffer and converts the 
data to the form dictated by the conversion 
code. The converted data is then moved 
into the main storage address assigned to 
the list item. 


In general, after a conversion routine 
has processed a list item, the I/O list 
section determines if that routine can be 
applied to the next list item or array ele- 
ment (if an array is being processed). The 
I/O list section examines a field count 
that indicates the number of times a par- 
ticular conversion code is to be applied to 
successive list items or successive ele- 
ments of an array. 


If the conversion code is to be repeated 
and if the previous list item was a vari- 
able, the I/O list section returns control 
to the load module. The load module again 
branches to the I/O list section and 
passes, aS an argument, the main storage 
address assigned to the next list item. 


The conversion routine that processed 
the previous list item is then given con- 
trol. This procedure is repeated until 
either the field count is exhausted or the 
input data for the READ statement is 
exhausted. 


If the conversion code is to ke repeated 
and if an array iS being processed, the I/C 
list section computes the main storage 
address of the next element in the array. 
The conversion routine that processed the 
previous element is then given control. 
This procedure is repeated until either all 
the array elements associated with a spe- 
cific conversion code are processed or the 
input data for the READ statement is 
exhausted. 


If the conversion code is not to be 
repeated, control is passed to the scan 
portion of IHCFCOMH to continue the scan of 
the FORMAT statement. If the Scan portion 
determines that a group of conversion codes 
is to be repeated, the conversion routines 
corresponding to those codes are applied to 
the next portion of the input data. This 
procedure is repeated until either the 
group count is exhausted or the input data 
for the READ statement is exhausted. 


If a group of conversion codes is not to 
be repeated and if the end of the FORMAT 
statement is not encountered, the next for- 
mat code is obtained. For a control type 
code, control is passed to the associated 
control routine to perform the indicated 
operation. For a conversion type code, 
control is returned to the load module if 
the previous list item was a variakle. The 
load module again branches to the I/O list 
section and passes, aS an argument, the 
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main storage address assigned to the next 
list item. Control is then passed to the 
conversion routine associated with the new 
conversion ccde. The conversion routine 
then processes the data for this list item. 
If the data that was just converted was 
placed into an element of an array and if 
the entire array has not been filled, the 
I/C:list section computes the main storage 
address of the next element in the array 
and passes control to the conversion rou- 
tine associated with the new conversion 
code. The conversion routine then pro- 
cesses the data for this array element. 
Suksequent I/O list processing for a READ 
requiring a format proceeds at the point 
where the field count is examined. 


If the scan portion encounters the end 
of the FORMAT statement and if all the list 
items are satisfied, control returns to the 
next sequential instruction within the load 
module. This instruction (part of the cal- 
ling sequence tc IHCFCCMH) branches to the 
closing section. If all the list items are 
not satisfied, control is passed to the I/O 
interface to read (via the READ macro 
instruction) the next input record. The 
conversion codes starting from the last 
left parenthesis are then repeated for the 
remaining list items. 


If the operation iS a write requiring a 
format, the I/O list section procesSing is 
Similar to that for a read requiring a for- 
mat. The main difference is that the 
conversion routines obtain data from the 
main storage addresses assigned to the list 
items rather than from an input buffer. 

The converted data is then transferred to 
an cutput buffer. If all the list items 
have not keen converted and transferred 
before the end-of-the FORMAT statement is 
encountered, control is passed to the I/C 
interface. The I/O interface writes (via 
the WRITE macro instruction) the contents 
of the current output buffer onto the out- 
put data set. The conversion codes start- 
ing from the last left parenthesis are then 
repeated for the remaining list items. 


Read/Write Not Reguiring a Format: In pro- 


cesSing a list item for a read not requir- 
ing a format, the I/O list section must 
know the main storage address assigned to 
the list item and the size of the list 
item. Their values are passed, as argu- 
ments, via the calling sequence to the I/0 
list section. The list item may be either 
a variable or an array. In either case, 
the number of bytes specified by the size 
of the list item is moved from the input 
buffer to the main storage address assigned 
to the list item. The I/O list section 
then returns control to the load module. 
The load module again Eranches to the I/C 
list section and passes, as arguments, the 
Main storage address assigned to the next 
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list item and the size of the list item. 
The I/0 list section moves the number of 
bytes specified by the size of the list 
item into the main storage address assigned 
to this list item. This procedure is 
repeated either until all the list items 
are satisfied or until the input data is 
exhausted. Control is then returned to the 
load module. 


If the operation iS a write not requir- 
ing a format, the I/O list section proces- 
Sing iS Similar to that described for a 
read not requiring a format. The main dif- 
ference is that the data is obtained from 
the main storage addresses assigned to the 
list items and is then moved to an output 
buffer. In addition, the segment length 
(1.e., the number of bytes in the record 
segment) and a code indicating the position 
of this segment relative to other segments, 
if any, of the Logical record are inserted 
in the segment control word. 


CLOSING SECTION: The compiler generates a 
calling sequence to one of two entry points 
in the closing section of IHCFCOMH each 
time it encounters the end of a READ or 
WRITE statement in the FORTRAN source 
module. The entry points correspond to the 
operations of read and write, requiring or 
not requiring a format. 


Read/Write Requiring a Format: If the 
operation is a read requiring a format, the 


closing section simply returns control to 
the load module to continue load module 
execution. If the operation is a write 
requiring a format, the cloSing section 
branches to the I/O interface. The I/C 
interface writes (via the WRITE macro 
instruction) the contents of the current 
I/O buffer (the final record) onto the out- 
put data set. The I/O interface then 
returns control to the closing section. 
The closing section, in turn, returns con- 
trol to the load module to continue jioad 
module execution. 


Read/Write Not Requiring a Format: If the 


operation is a read not requiring a format, 
the closing section branches to the I/O 
interface. The I/O interface reads (via 
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the READ macro instruction) successive 
records until the end of the logical record 
being read is encountered. (A FCRTRAN log- 
ical record consists of all the records 
necessary to contain the I/C list items for 
a WRITE statement not requiring a format.) 
When the I/O interface recognizes the end- 
of-logicai- record indicator, control is 
returned to the closing section. The clos- 
ing section, in turn, returns control to 
the load module to continue load module 
execution. 


If the operation is a write nct requir- 
ing a format, the cloSing section inserts: 
(1) the segment length (i.e., the number of 
kbytes in the record segment) and a code 
indicating that this segment is either the 
last or the only segment of the logical 
record into the segment control word of the 
I/C buffer to be written, and (2) an end- 
of-logical-record indicator into the last 
record of the I/O buffer being written. 

The closing section then branches to the 
I/O interface. The I/C interface writes 
(via the WRITE macro instruction) the con- 
tents of this I/O buffer onto the output 
data set. The I/O interface then returns 
control to the closing section. The clos- 
ing section, in turn, returns control to 
the load module to continue load rodule 
execution. 


Examples of IHCFCOMH READ/WRITE Statement 
Processing 


The following examples illustrate the 
opening section, I/O list section, and 
closing section processing performed by 
THCFCOMH for sequential access READ and 
WRITE statements, requiring or nct requir- 
ing a format. : 


Note: IHCFCOMH processing for the direct 
access READ, FIND, and WRITE statements is 
essentially the same as that described for 
the sequential access READ and WRITE state- 
ments. The main difference is that for 
direct access statements, IHCFCCMH branches 
to the direct access I/O interface (IHC- 
DIOSH) instead of to the sequential access 
I/C interface (IHCFIOSH). 


READ REQUIRING A FORMAT: The processing 
performed by IHCFCOMH for the following 
READ statement and FORMAT statement is 
illustrated in Table 32. 


READ (1,2) A,B,C 
2 FORMAT (3F12.6) 


IHCFCOMH ProcesSing for a READ 
Requiring a Format 


Table 32. 
Sn T 
{Opening |1. 
}Section | 

| | 

| | 

| | 

| [2s 
| | 

| | 

| {3. 
| | 
}-------- + 
{I/O List|1. 
|Section | 

| | 

| | 

| | 

| {2. 
| | 

| | 

| ee 
[ | 

| | 

| | 

| | 

| | 4. 
| | 

| | 

| 15. 
| | 

| | 

| | 

| | 

| |6. 
| | 
|-------- + 
{Closing |{1. 
{Section | 

| | 

| | 

| [2. 
| | 

| | 
ee mn: 


‘Receives control from load 


Receives control from load 
module and branches to IHC- 
FIOSH to initialize data set 
for reading. 


Passes control to scan por- 
tion of ITHCFCOMH. 


Returns control to load 
module. 


Receives control from load 
module, converts input data 
for A using IHCFCVTH, and 
moves converted data to A. 


Returns control to load 
module. 


module, converts input data 
for B, and moves converted 
data to B. 


Returns control to load 
module. 


Receives control from load 
module, converts input data 
for C, and moves converted 
data to C. 


Returns control to load 
module. 


Receives control from load 
module and closes out I/C 
operation. 


Returns control to load 
module to continue load 
module execution. 


ee 


WRITE REQUIRING A FORMAT: The processing 
performed by IHCFCOMH for the fcllowing 
WRITE statement and FORMAT statement is 
illustrated in Table 33. 


WRITE (3,2) (D(I) ,I=1,3) 
2 FORMAT (3F12.6) 


Takle 33. IHCFCOMH Processing for a WRITE 

Requiring a Format 

1. Receives control from load 
module and branches to IHC- 
FIOSH to initialize data set 
for writing. 


}Crenin 
|Sectio 


3 Q 


2. Passes control to scan por- 
tion of IHCFCOMH. 


3. Returns control to load 
module. 


|I/C List|1. Receives control from load 
| Section module, converts D(1), and 
moves D(1) to output buffer. 


2e Returns control to load 
module. 


3. Receives control from load 
module, converts D(2), and 
moves D(2) to output buffer. 


4. Returns control to load 
module. 


5. Receives control from load 
module, converts D(3), and 
moves D(3) to output buffer. 


6. Returns control to load 
module. 

1. Receives control from load 
module and branches to IHC- 
FIOSH to write contents of 
output buffer. 


|Closing 
| Section 


— ee ee ee ee ee wee ee ees oe ee ce ee ee ee ee ee oe 


2- Returns control to load 
module to continue load 
module execution. 


Appendix E: Object-Time Library Subprograms 173 


READ NOT REQUIRING A FORMAT: 


The proces- 


Sing performed by IHCFCOMH for the follow- 
ing READ statement is illustrated in Table 


X,Y,2Z 


IHCFCOMH Processing for a READ 


Not Requiring a Format 


34, 

READ (5) 
Table 34. 
Smet {oo 
|Opening |1. 
{Section | 

| | 

| | 

| | 

| {2. 
| | 

| | 
Gaerne 
{I/O Listj1. 
{Section | 

| | 

| | 

| 2s 
| [ 

| | 

| }3. 
| | 

| | 

| | 

| {4. 
| | 

| | 

| 15s 
| | 

| | 

| | 

| ,6. 
| | 
f==—2=s== {= 
{Closing |1. 
{}Section | 

| | 

| | 

| | 

| | 

| | 

| | 2. 
| | 

| | 
nae One ee L 
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Receives control from load 
module and branches to IHC- 
FIOSH to initialize data set 
for reading. 


Returns control to load 
module. 


Receives control from load 
module and moves input data 
tO As 


Returns control to load 
module. 


Receives control from load 
module and moves input data 
LO: SY. 


Returns control to load 
module. 


Receives control from load 
module and moves input data 
to Z. 


Returns control to load 
module. 


Receives control from load 
module and branches to IHC- 
FIOSH to read succesSive 
records until the end-of- 
logical-record indicator is 
encountered. 


Returns control to load 
module to continue load 
module execution. 


WRITE NOT REQUIRING A FCRMAT: 
Sing performed by IHCFCOMH for the follow- 


The proces- 


ing WRITE statement is illustrated in Table 


(W (J) ,J=1, 19) 


IHCFCOMH Processing for a WRITE 


Not Requiring a Format 


35. 

WRITE (6) 
eTable 35. 

Seo SeaSs 

{Opening |1. 

[Section | 

| | 

| | 

| | 

| eae 

| | 

}-------- + 

jI7C List|1. 

|Section | 

| | 

| | 

| |2. 

| | 

| | 

| [3% 

| | 

| | 

| | 

| [4. 

| | 

| | 

| |e 

| |. 

i | - 

| | 

| [5. 

| | 

| | 

| | 

| |6. 

| | 

<—==--S= + 

[Closing |1. 

{Section | 

| | 

| | 

| | 

| 

| J2. 

| | 

| | 

ane eee me erat 1 


Receives control from load 
module and branches to IHC- 
FIOSH to initialize data for 


writing. 


Returns control to load 
module. 


Receives control from load 
module and moves W(1) to 
output buffer. 


Returns control to load 
wodule. 


Receives control from load 
module and moves W(2) to 
cutput buffer. 


Returns control to load 
module. | 


load 
to 


Receives control from 
module and moves W (10) 
output buffer. 


Returns control to load 
module. 


ee ewe ee me eS SD a aeuee ERD oe ene ee <a ee TED oe ee eee ee ee eee cee eee ee eee ee eee ee eee ce oe ee 


Receives control from load 
module, inserts control 


information, and branches to 


IHCFIOCSH to write contents 
of output buffer. 


Returns control to load 
module to continue load 
module execution. 


READ/WRITE Statement Using NAMELIST 


Included in the calling sequence to 
IHCNAMEL* generated by the compiler when it 
detects a READ or WRITE uSing a NAMELIST is 
a pointer to the object-time namelist dic-— 
tionary associated with the READ or WRITE. 
This dictionary contains the names and 
addresses of the variables and arrays into 
which data is to be read or from which data 
is to be written. The dictionary also con- 
tains the information needed to select the 
conversion routine that is to convert the 
data to be placed into the variables or 
arrays, or to be taken from the variables 
and arrays. 


READ USING NAMELIST: The data set contain- 
ing the data to be input to the variakles 
or arrayS iS initialized and successive 
records are read until the one containing 
the namelist name corresponding to that in 
the namelist dictionary is encountered. 

The next record is then read and processed. 


The record is scanned and the first name 
is obtained. The name iS compared to the 
variable and array names in the namelist 
dictionary. If the name does not agree, an 
error is signaled and load module execution 
is terminated. If the name is in the dic- 
tionary, processing of the matched variakle 
or array iS initiated. 


Each initialization constant assigned to 
the variable or an array element is 
obtained from the input record. (One con- 
Stant is required for a variable. A number 
of constants equal to the number of ele- 
ments in the array is required for an 
array. A constant may be repeated for suc- 
cesSive array elements if appropriately 
specified in the input record.) The appro- 
priate conversion routine is selected 
according to the type of the variable or 
array element. Control is then passed to 
the conversion routine to convert the con- 
Stant and to enter it into itS associated 
variable or array element. 


The process is repeated for the second 
and subsequent names in the input record. 
When an entire record has been processed, 
the next is read and processed. 


Processing is terminated upon recogni- 
tion of the &END record. Control is then 
returned to the calling routine within the 
load module. 


me ee ee se ene ee ee cee a ee ee ee ee eee ee ee 


TIHCNAMEL is included in the load module 
only if reads and writes using NAMELISTs 
appear in the compiled program. Calls are 
made directly to FRDNL# (for READ) or to 
FWRNL# (for WRITE). 


Appendix E: 


WRITE USING NAMELIST: The data set upon 
which the variables and arrays are to ke 
written is initialized. The namelist name 
is oktained from the namelist dictionary 
associated with the WRITE, moved to an I/O 
buffer, and written. The processing of the 
variables and arrays is then initiated. 


The first variable or array namre in the 
dictionary is moved to an I/O buffer fol- 
lowed by an equal sign. The appropriate 
conversion routine is selected according to 
the type of the variable or array elements. 
Control is then passed to the conversion 
routine to convert the contents of the 
variakle or the first array element and to 
enter it into the I/C buffer. A comma is 
inserted into the buffer following the ccn- 
verted quantity. If an array is being pro- 
cessed, the contents of its second and sub- 
sequent elements are converted, uSing the 
same conversion routine, and placed into 
the I/O buffer, separated by commas. When 
all of the array elements have been pro- 
cessed or if the item processed was a vari- 
able, the next name in the dictionary is 
oktained. The process is repeated for this 
and subsequent variable or array names. 


If, at any time, the record length is 
exhausted, the current record is written 
and processing resumes in the normal 
fashion. 


When the last variable or array has been 
processed, the contents of the current 
record are written, the characters &END are 
moved to the buffer and written, and con- 
trcl is returned to the calling routine 
within the load module. 


I/O Device Manipulation Routines 


The I/O device manipulation routines of 
IHCFCOMH implement the BACKSPACE, REWIND, 
and END FILE source statements. These rou- 
tines receive control from within the load 
module via calling sequences that are 
generated by the compiler when these state- 
ments are encountered. 


Note: The I/O device manipulation routines 
apply only to sequential access I/O devices 
(e.g., tape units). BACKSPACE, REWIND, and 
ENDFILE requests for direct access data 
sets are ignored. 


The implementation of REWIND and END 
FILE statements is straightforward. The 
I/O device manipulation routines submit the 
approrriate control request to IHCFIOSH, 
the I/O interface module. After the 
request is executed, control is returned to 
the calling routine within the load module. 


The BACKSPACE statement is processed in 


a Similar fashion. However, before control 
is returned to the calling routine, it is 
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determined whether the record backspaced 
over is an element of a data set that does 
not require a format. If the record is an 
element of such a data set, that record is 
read into an I/O buffer and the segment 
control word iS examined. If it indicates 
that the record is the first or only seg- 
ment of the logical record, a backspace 
control request is issued and control is 
returned to the calling routine. If the 
segment control word indicates that this is 
the last or an intermediate segment, two 
backspace control requests are issued to 
backspace to the beginning of the preceding 
record segment. This record is then read 
in and its segment control word examined. 
If it is still not the first segment, two 
more backspace control requests are issued. 
This process continues until the first seg- 
ment is read. Then a backspace control 
request iS issued and control is returned 
to the calling routine. If the record is 
not an element of such a data set, control 
is returned directly to the calling 
routine. 


Write-to-Operator Routines 


The write-to-operator routines of IHCF- 
COMH implement the STOP and PAUSE source 
statements. These routines receive control 
from within the load module via calling 
sequences generated by the compiler upon 
recognition of the STOP and PAUSE 
statements. 


STOP: A write-to-operator (WTO) macro 
instruction is issued to display the mes- 
sage associated with the STOP statement on 
the console. Load module execution is then 
terminated by passing control to the pro- 
gram termination routine of IHCFCOMH. 





PAUSE: A write-to-operator-with-reply 
(WTOR) macro instruction is issued to dis- 
play the message associated with the PAUSE 
statement on the console and to enable the 
operator's reply to be transmitted. A WAIT 
macro instruction is then issued to deter- 
mine when the operator's reply has been 
transmitted. After the reply has been 
received, control is returned to the cal- 
ling routine within the load module. 


Utility Routines 


The utility routines of IHCFCOMH perform 
the following functions: 


e Process object-time error messages. 

e Process arithmetic-type program 
interruptions. 

e Process specification interruptions. 

e Terminate load module execution. 


PROCESSING OF ERROR MESSAGES: The error 


message procesSing routine (IBFERR) 
receives control from various FORTRAN 
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library subprograms when they detect ter- 
minal object-time errors. 


Error message processing consists of 
initializing the data set upon which the 
message is to ke written and of writing the 
message and a diagnostic traceback. Con- 
trol is then passed to the routine for ter- 
winating load module execution. 


PROCESSING OF INTERRUPTIONS: The interrupt 
routine (IBFINT) of IHCFCOMH initially 
receives control from within the load 
module via a compiler-generated calling 
sequence. The call is placed at the start 
of the executakle coding of the load module 
so that the interrupt routine can set up 
the program interrupt mask. Subsequent 
entries into the interrupt routine are made 
through specification or arithmetic-type 
interruptions. 


The interrupt routine sets up the pro- 
gram interrupt mask by means of a SPIE 
macro instruction. This instruction speci- 
fies the type of interruptions that are to 
cause control to be passed to the interrupt 
routine, and the location within the rou- 
tine to which control is to be passed if 
the specified interruptions occur. After 
the mask has been set, control is returned 
to the calling routine within the load 
module. 


In processing an interruption, the first 
step taken by the interrupt routine is to 
determine its type. 


A. Arithmetic Interruptions: If exponen- 


tial overflow or underflow has occurred, 
the appropriate indicators, which are 
referred to by OVERFL (a library subpro- 
gram), are set. If any type of divide 
check caused the interruption, the indica- 
tor referred. to by DVCHK (also a library 
Subprogram) is set. 


Regardless of the type of interruption 
that caused control to be‘given to the 
interrupt routine, the old program PSW is 
written out for diagnostic purposes. 


After the interruption has been pro- 
cessed, control is returned to the inter- 
rupted routine at the point of 
interruption. 


Be. Specification Interruptions: If an 


interrupt is caused by a specification 
exception and the boundary alignment option 
was specified by the user during system 
generation, the koundary adjustment routine 
(I[HCADJST) is loaded from the link library 
(SYS1.LINKLIB) . 


This routine determines whether or not 
the interruption was caused by an instruc- 
tion that referred to improperly aligned 


data. If not, the routine causes abnormal 
termination of the load module. If so, the 
routine: 


1. Causes message IHC210I, which contains 
the main program PSW, to ke generated. 


2. Moves the misaligned data to a proper- 
ly aligned boundary. 


3. Reexecutes the instruction that refers 
to the data. 


If no interruption occurs when the 
instruction is reexecuted, the data is 
moved back to its original location. if 
there is a new condition code, it is placed 
in the PSW of the Program Interruption Ele- 
ment (PIE). The boundary adjustment rou- 
tine then returns control to the control 
program, which loads the PSW of the PIE to 
effect a return to the interrupted program. 


If a divide check, exponential overflow 
or underflow interruption occurs when the 
instruction is reexecuted, the interruption 
will be handled as described under "Arith- 
metic Interruptions." 


If a data, protection, or addressing 
interruption occurs when the instruction is 
reexecuted, the boundary adjustment routine 
generates the message IHC210I. The PSW 
information in this message gives the cause 
of the interruption and the location of the 
instruction in the main program that caused 
the interruption. Then, Since processing 
cannot continue, the routine issues a SPIE 
macro instruction to remove specification 
interruptions from those interruptions 
handled by this routine and reexecutes the 
instruction. This causes abnormal termina- 
tion of the load module because of the ori- 
ginal specification error. 


PROGRAM TERMINATION: The load module ter- 
Mination routine (IBEXIT) of IHCFCOMH 
receives control from various library sub- 
programs (e.g., DUMP and EXIT) and from 
other IHCFCOMH routines (e.g., the routine 
that processes the STOP statement) . 


This routine terminates execution of the 
load module by the following means: 


e Calling the appropriate I/O interface 
(s) to check (via the CHECK macro 
instruction) outstanding write 
requests. 


e Issuing a SPIE macro instruction with 
no parameters indicating that the FOR- 
TRAN object module no longer desires to 
give special treatment to program 
interruptions and does not want mask- 
able interruptions to occur. 


e Returning to the operating system 
supervisor. 


CCNVERSICN ROUTINES (IHCFCVTH) 


The conversion routines (refer to Takle 
37) either convert data to be placed into 
I/C list items or convert data to be taken 
from I/O list items. 


These routines receive control either 
from the I/O list section of IHCFCOMH dur- 
ing its processing of list items for READ/ 
WRITE statements requiring a format, from 
the routines that process READ/WRITE state- 
ments using a NAMELIST, or from the DUMP 
and PDUMP subprograms. 


Each conversion routine iS associated 
with a conversion tyre format code and/or a 
type. If an I/C list item for READ/WRITE 
statement requiring a format is Leing pro- 
cessed, the conversion routine is selected 
according to the conversion type format 
code which is to be applied to the list 
item. If a list item for a READ/WRITE 
uSing a NAMELIST is being processed, the 
conversion routine is selected according to 
the type of the list item. 


If a READ statement is being imple- 
mented, the conversion routine oktains data 
from the I/O buffer, converts it according 
to its associated conversion type format 
code or type, and enters the converted data 
into the list item. The process is 
reversed if a WRITE statement is being 
implemented. 


For the DUMP and PDUMP subprograms, the 
format code parameter passed to them deter- 
mines the selection of the output conver- 
Sion routine to be used to place the output 
in the desired form. 


ITHCFICSH 


IHCFIOSH, the object-time FCRTRAN 
sequential access input/output data mwanage- 
ment interface, receives I/C requests from 
IHCFCOMH and sukmits them to the approrpri- 
ate BSAM (basic sequential access method) 
routines and/or open and close routines for 
execution. 


Chart 26 illustrates the overall logic 
and the relationship among the routines of 
IHCFICSH. Table 38, the IHCFIOSH routine 
directory, lists the routines used in IHC- 
FIOSH and their functions. 


BLOCKS AND TABLES USED 


IHCFIOSH uses the following blocks and 
takle during its processing of sequential 
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access input/output requests: (1) unit 
blocks, and (2) unit assignment table. The 
unit blocks are used to indicate I/O acti- 
vity for each unit number (1i.e., data set 
reference number) and to indicate the type 
of operation requested. In addition, the 
unit blocks contain skeletons of the data 
event control blocks (DECB) and the data 
control blocks (DCB) that are required for 
I/O operations. The unit assignment table 
is used as an index to the unit blocks. 


Unit Blocks 


The first reference to each unit number 
(data set reference number) by an input/ 
output operation within the FORTRAN load 
module causes IHCFIOSH to construct a unit 
block for each unit number. The main 
storage for the unit blocks is obtained by 
ITHCFIOSH via the GETMAIN macro instruction. 
The addresses of the unit blocks are placed 
in the unit assignment table as the unit 
blocks are constructed. All subsequent 
references to the unit numbers are then 
made through the unit assignment table. 
Figure 57 illustrates the format of a unit 
block for a unit that is defined as a 
sequential access data set. 


aaa ; eae i : ee 1 
| ABYTE | BBYTE| CBYTE| LIVECNT | 

pono abo ad el ea 

[Address of Buffer 1 | 
}————~—-—-—~——-——-—~—-—--—~—-—~-—-—-—-——— 4| Housekeeping 
[Address of Buffer 2 |( Section 
Ss | 

{|Current buffer pointer | 
See eee ee ee ed 

{Record offset | 

BS eee ae eee 4 

|DECB skeleton section | 

ae a ge ee | 


{DCB skeleton section | 

ie ee einen ane a ere Rae nn eR eRe eT 

Figure 57. Format of a Unit Block fora 
Sequential Access Data Set 


Each unit block is divided into three 
sections: a housekeeping section, a DECB 
skeleton section, and a DCB skeleton 
section. 


HOUSEKEEPING SECTICN: The housekeeping 
section iS maintained by IHCFIOSH. The 
information contained in it is used to ind- 
icate data set type, to keep track of I/0 
buffer locations, and to keep track of 
addresses internal to the I/0 buffers to 
enable the processing of blocked records. 
The fields of this section are: 


e ABYTE. This field, containing the data 
set type passed to IHCFIOSH by IHCF- 
COMH, can be set to one of the 
following: 
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DECB SKELETON SECTION: 


FO - Input data set requiring a format. 


FF —- Output data set requiring a 
format. 
00 - Input data set not requiring a 
format. 
OF - Output data set not requiring a 
format. 
e PBBYTE. This field contains bits that 


are set and examined by IHCFIOSH during 
its processing. The bits and their 
reanings are as follows: 


Bit on 


- exit to IHCFCOMH on I/C error 

- I/O error occurred 

- current buffer indicator 

- not used 

end-of-current buffer indicator 
- blocked data set indicator 

- variable record format switch 

- not used 


SANE WH a © 
I 


e CBYTE. This field also contains bits 
that are set and examined by IHCFIOSH. 
The kits and their meanings are as 
follows: 


Bit on 


- data control block opened 

-~ data control block not TCLOSEd 

data control block not previously 

crened 

- buffer pool attached 

- data set not previously rewound 

data set not previously backspaced 

- concatenation occurring -- reissue 
REAL 

7 - data set is DUMMY 


NO — © 
t 


Nun ew 
| 


e LIVECNT. This field indicates whether 
any I/O operation performed for this 
data set is unchecked. (A value of 1 
indicates that a previous read or write 
has not been checked; a value of 0 
indicates that all previous read and 
write operations for this data set have 
been checked.) 


e Address of Buffer 1 and Address of 
Buffer 2. These fields contain point- 
ers to the two I/O buffers obtained 
during the opening of the data control 
block for this data set. 


e Current Buffer Pointer. This field 
contains a pointer to the I/O buffer 
currently being used. 


e Record Offset. This field contains a 
pointer to the current logical record 
within the current buffer. 


The DECB (data 
event control block) skeleton section is a 
klock of main storage within the unit 


block. It is of the same form as the DECB 
constructed by the control program for an L 
form of an S-type READ or WRITE macro 
instruction (refer to the publication IBM 


Ssystem/360 Operating System: Supervisor 


and Data Management Macro Instructions). 
The various fields of the DECB skeleton are 


filled in by IHCFIOSH; the completed Llock 
is referred to when IHCFIOSH issues a read/ 
write request to BSAM. The read/write 
field is filled in at open time. For each 
I/O operation, IHCFIOSH supplies IHCFCOMH 
with: (1) an indication of the type of 
operation (read or write), and (2) the 
length of and a pointer to the I/0 buffer 
to be used for the operation. 


DCB SKELETON SECTION: The DCB (data con- 
trol block) skeleton section is a block of 
Main storage within the unit block. It is 
of the same form as the DCB constructed hy 
the control program for a DCB macro 
instruction under BSAM (refer to the publi- 


cation IBM System/360 Operating System: 


Supervisor and Data Management Macro 
Instructions). The various fields of the 


DCB skeleton are filled in by the control 
program when the DCB for the data set is 
opened (refer to the publication IBM 
system/360 Operating System: Concepts and 
Facilities). (Standard default values may 
also be inserted in the DCB skeleton by 
IHCFIOSH. Refer to “Unit Assignment Table" 
for a discussion of when default values are 
inserted into the DCB skeleton.) 


Unit Assignment Table 


The unit assignment table (IHCUATBL) 
resides on the FORTRAN system library 
(S¥YS1.FORTLIB). Its Size depends on the 
maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (2 99) is speci- 
fied by the user during the system genera- 
tion process via the FORTLIB macro 
instruction. 


The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSH. It 
is included once, by the linkage editor, in 
the FORTRAN load module as a result of an 
external reference to it within IHCFICSH 
and/or IHCDIOSH. 


The unit assignment table contains a 16 
byte entry for each of the unit numbers 
that can be referred to by the user. These 
entries differ in format depending on 
whether the unit has been defined as a 
sequential access or a direct access data 
set. 


Figure 58 illustrates the format of the 
unit assignment table. 


Appendix E: 


[being used for current | 


| operation | tn x 16 4 bytes | 
er anata | Seaman ea:, auced seellareas Viccaee ueaieean mal Gaui cs an eR 
| ERRMSG | READ | PRINT | PUNCH | 
| DSRN2 | DSRN? | DSRN* | DSRN® 

sae Rane f emer SaacenSeL! Homes ee (ne Maree mene epee even nemt 


= 
on 

he 
ct 
) 
Y) 


— + — + —— 4+ —— —4 
{> 
bo 
ke 
ct 
© 
49) 


Co 
oO 

hk 
ct 
0) 
6) 


ee eee ee ee ee ee cee ee eee mt cere ce EE eee ee ee Te eee eee ED ee ee EY Ee ee eee Ome SEES tee <P ee eS A 


eee a eee ED GD RED eR CR a EE ED AED ED ED EY EEE SS GEE SETS UP Ee eS <eeew ace mm aA GS aN Ge <eme RE ED cD ne ee a a co a omen 


1m is the maximum number of units that 
can be referred to by the FORTRAN load 
module. The size of the unit table is 
equal to (8 + n x 16) bytes. 
2Unit number (DSRN) of error output 
device. 
3Unit number 
read of the form: 
*Unit number (DSRN) 
a f~rint operation of the form: 
,list. 
nit number 


4-4 — 4} — 4 


(DSRN) of input device for a 
READ b,list. 
of output device for 


PRINT 





5 (DSRN) 


of output device for 
runch operation of the form: PUNCH 
,iist. 

6The UBLOCKn field contains either a 
pointer to the unit block constructed 
for unit number n if the unit is being 
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the unit is not being used. 

7The default values for the various unit 
numbers are specified by the user and 
are assembled into the unit assignment 
takle entries during the system genera- 
tion process. The default values are 
used only by IHCFIOSH; they are ignored 
by IHCDIOSH. 

8If the unit is defined as a direct 
access data set, the LISTn field con- 
tains a pointer to the parameter list 
that defines the direct access data set. 
Ctherwise, this field contains a value 
Of Ts : 


ee eee ee et eee cee cee ee ee te ee ee rem cere co cere et cet ete ete eer em em <ee CORD SORE <A cE CEE ENED ED EET ED AEE ETE EE SEED ED ED 
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Figure 58. Unit Assignment Table Format 
Because IHCFIOSH deals only with sequen- 
tial access data sets, the remainder of the 
discussion on the unit assignment takle is 
devoted to unit assignment table entries 
for sequential access data sets. If 
IHCFIOSH encounters a reference to a direct 
access data set, it iS conSidered as an 
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error, and control is passed to the load 
module termination routine of IHCFCOMH. 


The pointers to the unit blocks created 
for sequential data sets are inserted into 
the unit asSignment table entries by IHC- 
FIOSH when the unit blocks are constructed. 


Note: Default values are standard values 
that IHCFIOSH inserts into the appropriate 
fields (e.g., BUFNO) of the DCB skeleton 
section of the unit blocks if the user 
either: 


e Causes the load module to be executed 
via a cataloged procedure, or 


e Fails, in stating his own procedure for 
execution, to include in the DCB param- 
eter of his DD statements those sub- 
parameters (e.g., BUFNC) he is per- 
mitted to include (refer to the rpukli- 


cation IBM System/360 Operating System: 
FORTRAN IV_ (H) Programmer's Guide). 


Control is returned to IHCFIOSH during 
data control block opening so that it can 
determine if the user has included the sub- 
parameters in the DCB parameter of his DD 
Statements. IHCFIOSH examines the DCB 
Skeleton fields corresponding to user- 
permitted subparameters, and upon encoun- 
tering a null field (indicating that the 
user has not specified the subparameter) , 
inserts the standard value (i.e., the 
default value) for the subparameter into 
the DCB skeleton. (If the user has 
included these subparameters in his DD 
statement, the control program routine per- 
forming data control block opening inserts 
the sukparametexr values, before giving con- 
trol to IHCFIOSH, into the DCB skeleton 
fields reserved for those values.) 


BUFFERING 


All input/output operations are double 
buffered. (The double buffering scheme can 
be overridden by the user if he specifies 
in a DD statement: BUFNO=1.) This implies 
that during data control block opening, two 
buffers will be obtained. The addresses of 
these buffers are given alternately to 
IHCFCOMH as pointers to: 


e Buffers to be filled (in the case of 
output) . 


-@ Information that has been read in and 
is to be processed (in the case of 
input). 

COMMUNICATION WITH THE CONTROL PROGRAM 
In requesting services of the control 


program, IHCFIOSH uses L and E forms of 
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NC PREVICUS OPERATION: 


S-type macro instructions (refer to the 


publication IBM System/360 Cperating Sys- 


tem: Supervisor and Data Management Macro 
Instructions). 


CPERATION 


The processing of IHCFIOSH is divided 
into five sections: initialization, read, 
write, device manipulation, and cloSing. 
When called ky IHCFCOMH, a section of IHC- 
FIOSH performs its function and then 
returns control to IHCFCOMH. 


Initialization 


The initialization action taken by IHC- 
FIOSH depends upon the nature of the pre- 
vious I/O operation requested for the data 
set. The previous operation possibilities 
are: 


No previous operation. 

Previous oreration read or write. 
Previous operation backspace. 
Previous operation write end-of-data 
set. 

e Previous operation rewind. 


If no previous 
operation has been performed on the unit 
specified in the I/O request, the initiali- 
zation section generates a unit block for 
the unit number. The data set to ke 
created is then opened (if the current 
operation is not rewind or kackspace) via 
the OPEN macro instruction. The addresses 
of the I/C buffers, which are oktained dur- 
ing the opening process and placed into the 
DCB skeleton, are placed into the appropri- 
ate fields of the housekeeping section of 
the unit block. The DECB skeleton is then 
set to reflect the nature of the operation 
(read or write), the format of the records 
to ke read or written, and the address of 
the I/O buffer to be used in the operation. 


If the requested operation iS a write, a 
pointer to the kuffer position, at which 
IHCFCOMH is to place the record to be writ- 
ten, and the block size or logical record 
length (to accommodate blocked logical 
records) are placed into registers, and 
control is returned to IHCFCOMH. 


If the requested operation is a read, a 
record is read, via a READ macro instruc- 
tion, into the I/O buffer, and the orfera- 
tion is checked for completion via the 
CHECK macro instruction. A pointer to the 
location of the record within the buffer, 
along with the number of bytes read or the 
logical record length, are placed into 
registers, and control is returned to 
IHCFCOMH. 


Note: During the opening process, control 
is returned to the IHCDCBXE routine in IHC- 
FIOSH. This routine determines if the data 
set being opened is a 1403 printer. If it 
is, the RECFM field in the DCB for the data 
set is altered to machine carriage control 
(FM). In addition, a pointer to the unit 
block generated for the printer, and the 
physicai address of the printer are placed 
into a control block area (CTLBLK) for the 
printer within IHCFIOSH. CTLBLK also con- 
tains a third print buffer. This buffer is 
used in conjunction with the two buffers 
already obtained for the printer. 





Figure 59 iliustrates the format of 
CTLBLK. 


Ge rg ee ae eo 
CTLBLK|a (BUF 3) | 4 bytes] 
|---------------------—--- }--------- { 
Ja (unit block) | 4 kytes| 
Sg ne ee AS poe See ae 
Ja(printer) |record length] 4 bytes] 
a ea che eS me aE a ae i eee 
[7 FTOO | 4 bytes| 
pacer eS aaa ae yee ae eee 
{1 FOO1 | 4 bytes| 
EO Fe By etn ea ln tet 
BUF3 |third print buffer {144 kytes| 
ate ak ae en 
{7Used in the task input/output | 
| table (TIOT) search. 
nem eer Ee eR tere le Pn ON ee ea ee SE ae ON J 
Figure 59. CTLBLK Format 
PREVIOUS OPERATION READ OR WRITE: If the 


prévious operation performed on the unit 
specified in the present I/O request was 
either a read or write, the initialization 
section determines the nature of the pres- 
ent I/O request. If it is a write, a 
pointer to the buffer position, at which 
IHCFCOMH is to place the record to be writ- 
ten, and the block size or logical record 
length are placed into registers, and con- 
trol is returned to IHCFCOMH. 


If the operation to be performed is a 
read, a pointer to the buffer location of 
the record to be processed, along with the 
number of bytes read or logical record 
length, are placed into registers, and con- 
trol is returned to IHCFCOMH. 


PREVIOUS OPERATION BACKSPACE: If the pre- 
vious operation performed on the unit spe- 
cified in the present I/O request was a 
backspace, the initialization section 
determines the type of the present orpera- 
tion (read or write) and modifies the DECB 
Skeleton, if necessary, to reflect the 
operation type. (If the operation type is 
the same as that of the operation that pre- 
ceded the backspace request, the DECB 
skeleton need not be modified.) Subsequent 
processing steps are the same as those 
described for “No Previous Operation," 
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Starting at the point after the DECB skele- 
ton is set to reflect operation type. 


PREVICUS OPERATICN WRITE END-CF-DATA SET: 


If the previous operation performed on the 
unit specified in the present I/C request 
waS a write end-of-data set, a new data set 
uSing the same unit number is to be 
created. In this case, the initialization 
section closes the data set. Then, in 
order to establish a correspondence ketween 
the new data set and the DD statement 
describing that data set, IHCFIOSH incre- 
ments the unit sequence number of the 
ddname. (The ddname is placed into the 
agrropriate field of the DCB skeleton prior 
to the opening of the initial data set 
associated with the unit number.) During 
the opening of the data set, the ddname 
will be used to merge with the aprropriate 
DD statement. The data set is then opened. 
Suksequent processing steps are the same as 
those described for "No Previous Cpera- 
tion," starting at the point after the data 
set is opened. 


PREVIOUS OPERATION REWIND: If the previous 
operation performed on the unit specified 
in the present I/O request was a rewind, 
the ddname iS initialized (set to FTxxF001) 
in order to establish a correspondence 
between the initial data set associated 
with the unit number and the DD statement 
describing that data set. The data set is 
then opened. Subsequent processing steps 
are the same as those descriked for "No 
Previous Operation," starting at the point 
after the data set is opened. 


Read 


The read section of IHCFICSH performs 
two functions: (1) reads physical records 
into the buffers obtained during data set 
opening, and (2) makes the contents of 
these buffers availakle to IHCFCCMH for 
processing. 


If the records being processed are 
blocked, the read section does nct read a 
physical reccrd each time it is given con- 
trol. IHCFICSH only reads a physical rec- 
ord when all of the logical records of the 
klocked record under consideration have 
been processed by IHCFCOMH. However, if 
the records being processed are either 
unklocked or of U-format, the read section 
of IHCFIOSH issues a READ macro instruction 
each time it receives control. 


The reading of records by this section 
is overlapped. That is, while the contents 
of one buffer are being processed, a phys- 
ical record is keing read into the other 
buffer. When the contents of one buffer 
have keen processed, the read into the 
other buffer is checked for completion. 
Upon completion of the read operation, pro- 
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cessing of that buffer's contents is 
initiated. In addition, a read into the 
second buffer is initiated. 


Each time the read section is given con- 
trol it makes the next record availakle to 
IHCFCOMH for processing. (In the case of 
blocked records, the record presented to 
IHCFCOMH is logical.) The read section of 
IHCFIOSH places: (1) a pointer to the 
record's location in the current I/O buff- 
er, and (2) the number of bytes read or 
logical record length into registers, and 
then returns control to IHCFCOMH. 


Write 


The write section of IHCFIOSH performs 
two functions: (1) writes physical rec- 
ords, and (2) provides IHCFCOMH with buffer 
Space in which to place the records to ke 
written. 


If the records being written are 
blocked, the write section does not write a 
physical record each time it is given con- 
trol. IHCFIOSH only writes a physical rec- 
ord when all of the logical records that 
comprise the blocked record under consi- 
deration have been placed into the I/0O 
buffer by IHCFCOMH. However, if the rec- 
ords being written are either unblocked or 
of U-format, the write section of IHCFIOSH 
issues a WRITE macro instruction each time 
it receives control. 


The writing of records by this section 
is overlapped. That is, while IHCFCOMH is 
filling one buffer, the contents of the 
other buffer are being written. When an 
entire buffer has been filled, the write 
from the other buffer is checked for com- 
pletion. Upon completion of the write 
operation, IHCFCOMH starts placing records 
into that buffer. In addition, a write 
from the second buffer is initiated. 


Each time the write section is given 
control, it provides IHCFCOMH with buffer 
Space in which to place the record to he 
written. IHCFIOSH places: (1) a pointer 
to the location within the current buffer 
at which IHCFCOMH is to place the record, 
and (2) the block size or logical record 
length into registers, and then returns 
control to IHCFCOMH. 


Note: The write section checks to see if 
the data set being written on is a 1403 
printer. If it is, the carriage control 
character is changed to machine code, and 
three buffers, instead of the normal two, 
are used when writing on the printer. 


ERROR PROCESSING: If an end-of-data set or 
an I/O error is encountered during reading 
or writing, the control program returns 
control to the location within IHCFICSH 
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that was specified during data set initia- 
lization. In the case of an I/O error, 
IHCFICSH sets a Switch to indicate that the 
error has occurred. Control is then 
returned to the control program. The con- 
trol program completes its processing and 
returns control to IHCFIOSH, which interro- 
gates the switch, finds it to be set, and 
passes control to the I/O error routine of 
THCFCOMH. 


In the case of an end-of-data set, IHC- 
FICSH simply passes control to the end-of- 
data set routine of IHCFCOMH. 


Chart 27 illustrates the execution-tire 
I/7C recovery procedure for any I/C errors 
detected by the I/O supervisor. 


Device Manipulation 


The device manipulation section of IHC- 
FIOSH processes backspace, rewind, and 
write end-of-data set requests. 


IHCFIOSH processes the back- 
Space request Ly issuing a BSP (physical 
backspace) macro inStruction. It then 
grlaces the data set type, which indicates 
the format requirement, into a register and 
returns control to IHCFCOMH. (ITHCFCOMH 
needs the data set type to determine its 


BACKSPACE: 


‘ subsequent processing.) 


REWIND: IHCFIOSH processes the rewind 
request by issuing a CLCSE wacro instruc- 
tion, using the REREAD option. This option 
has the same effect as a rewind. Control 
is then returned to IHCFCOMH. 


WRITE END-OF-DATA SET: IHCFICSH processes 
this request by issuing a CLCSE macro 
instruction, type = T. It then frees the 
I/O buffers by issuing a FREEFCCL macro 
instruction, and returns control to 
IHCFCOMH. 


Closing 


The closing secticn of IHCFICSH examines 
the entries in the unit assignment takle to 
determine which data control blocks are 
oren. In addition, this section ensures 
that all write operations for a data set 
are completed before the data control block 
for that data set is closed. This is done 
by issuing a CHECK macro instruction for 
all double-kuffered output data sets. Ccn- 
trol is then returned to IHCFCCMH. 


Note: If a 1403 printer is being used, a 
write from the last print buffer is issued 
to insure that the last line of output is 
written. 


IHCDIOSH 


IHCDIOSH, the object-time FCRTRAN direct 
access input/output data management inter- 
face, receives I/O requests from IHCFCOMH 
and submits them to the appropriate BDAM 
(basic direct access method) routines and/ 
or open and close routines for execution. 
(For the first I/O request involving a ncon- 
existent data set, the appropriate BSAM 
routines must be executed prior to linking 
to the BDAM routines. The BSAM routines 
format and create a new data set consisting 
of blank records.) 


IHCDIOSH receives control from: (1) the 
initialization section of the FORTRAN load 
module if a DEFINE FILE statement is 
included in the source module, and (2) 
FCOMH whenever a READ, WRITE, or FIND 
direct access statement 1S encountered in 
the load module. 


IHC- 


Charts 28 and 29 illustrate the overall 
logic and the relationship among the rou- 
tines of IHCDICSH. Table 39, the IHCDIOSH 
routine directory, lists the routines used 
in IHCDIOSH and their functions. 


BLOCKS AND TABLE USED 


ITHCDIOSH uses the following blocks and 
table during its processing of direct 
access input/output requests: (1) unit 
blocks, and (2) unit asSignment takle. The 
unit blocks are used to indicate I/0 
activity for each unit number (i-.e., data 
set reference number) and to indicate the 
type of operation requested. In addition, 
each unit block contains skeletons of the 
data event control blocks (DECB) and the 
data control block (DCB) that are required 
for I/O operations. The unit assignment 
table is used as an index to the unit 
blocks. 


Unit Blocks 


The first reference to each unit number 
(i.e., data set reference number) by a 
direct access input/output operation within 
the FORTRAN load module causes IHCDIOSH to 
construct a unit block for each of the 
referenced unit numbers. The main storage 
for the unit blocks is obtained by IHCDIOSH 
via the GETMAIN macro instruction. The 
addresses of the unit blocks are inserted 
into the corresponding unit assignment 
table entries as the unit blocks are con- 
Structed. Subsequent references to the 
unit numbers are then made through the unit 
assignment table. 


Figure 60 illustrates the format of a 
unit block for a unit that has been defined 
aS a direct access data set. 
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panne adalat ares ay ma a | are sie { 
| BLKREFA | 4 kbytes | 
}------- y7--------------------- +---------~- { 
| STATUSB | NXTBUF l 4 bytes | 
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DCB {| 104 bytes | 
aa i oe Neen mee creme J 
Figure 60. Format of a Unit Block for a 


Direct Access Data Set 


The meanings of the various unit Elock 
fields are outlined below. 


ICTYPE: This field, containing the data 
set type passed to IHCDIOSH by IHCFCCMH, 
can ke set to one of the following: 

FO - input data set requiring a format 


FF - output data set requiring a format 


00 - input data set not requiring a 
format 


OF - output data set not requiring a 
format 


STATUSU: This field specifies the status 
of the associated unit number. The bits 
and their meanings are as follows: 
Bit on 
0 - not used 
1 - error occurred 


2 - two buffers are being used 


3 - data control block for data set is 
open 


4-5 10- U form specified in DEFSINE 
FILE statement 


01 - E form specified in DEFINE 
FILE statement 


11 - L form specified in DEFINE 
FILE statement 


6-7 not used 


Note: IHCDICSH refers only to bits 1, 2, 


and 3. 
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RECNUM: This field contains the number of 
records in the data set as specified in the 
parameter list for the data set ina DEFINE 
FILE statement. It is filled in by the 
file initialization section after the data 
control block for the data set is opened. 


STATUSA: This field specifies the status 
of the buffer currently being used. The 
bits and their meanings are as follows: 


Bit on 


0 - READ macro instruction has been 
issued 


1 - WRITE macro instruction has been 
issued 


2 - CHECK macro instruction has Leen 
issued 


3-7 Not used 


CURBUF: This field contains the address of 
the DECB skeleton currently being used. It 
1S initialized to contain the address of 
the DECBA skeleton by the file initializa- 
tion section of IHCDIOSH after the data 
control block for the data set is opened. 


BLKREFA: This field contains an integer 
that indicates either the relative position 
Within the data set of the record to be 
read, or the relative position within the 
data set at which the record is to be writ- 
ten. It is filled in by either the read or 
write section of IHCDIOSH prior to any 
reading or writing. In addition, the 
address of this field is inserted into the 
DECBA skeleton by the file initialization 
section of IHCDIOSH after the data control 
block for the data set is opened. 


STATUSB: This field specifies the status 
of the next buffer to be used if two buf- 
fers are obtained for this data set during 
data control block opening. The bits and 
their meanings are the same as descriked 
for the STATUSA field. However, if only 
one buffer is obtained during data control 
block opening, this field is not used. 


NXTBUF: This field contains the address of 
the DECB skeleton to be used next if two 
buffers are obtained during data control 
block opening. It is initialized to con- 
tain the address of the DECBB skeleton by 
the file initialization section of IHCDIOSH 
after the data control block for the data 
set is opened. However, if only one buffer 
is obtained during data control block open- 
ing, this field is not used. 


BLKREFB: The contents of this field are 
the same as described for the BLKREFA 
field. It is filled in either by the read 
or the write section of IHCDIOSH prior to 
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any reading cr writing. In addition, the 
address of this field is inserted into the 
DECRB skeletcn by the file initialization 
section of IHCDIOSH after the data control 
klock for the data set is opened. However, 
if only one buffer is obtained during data 
control kLlock opening, this field is not 
used. 


DECBA SKELETCN: This field contains the 
DECB (data event control block) skeleton to 
ke used when reading into or writing from 
the current kuffer. It is of the same forn 
as the DECB constructed by the control pro- 
gram for an L form of an S-type READ or 
WRITE macro instruction under BDAM (refer 
to the puklication IBM System/360 Operating 
System: Supervisor and Data Management 
Macro Instructions). 


The various fields of the DECBA skeleton 
are filled in ky the file initialization 
section of IHCDIOSH after the data control 
bklock for the data set is opened. The com- 
pleted DECB is referred to when IHCDIOSH 
issues a read or a write request to BDAM. 
For each I/O operation, IHCDICSH suprlies 
IHCFCOMH with the address of and the size 


of the buffer to be used for the operaticn. 


DECEB SKELETCN: The DECBB skeleton is used 
when reading into or writing fronrw the next 
buffer. Its contents are the same as 
described for the DECBA skeleton. The 
CECERB skeleton is completed in the same 
Wanner as described for the DECBA skeleton. 
However, if only one buffer is obtained 
Guring data control -Llock opening, this 
field is not used. 





DCB SKELETON: This field contains the DCB 
(data control block) skeleton for the asso- 
ciated data set. It is of the same form as 
the DCB constructed by the control prograr 
for a DCB macro instruction under BDAM 
(refer to the publication IBM System/360 


Cperating System: Supervisor and Data 
Management Macro Instructions). 


The various fields of the DCB skeleton 
are filled in by the control program when 
the DCB for the data set iS opened (refer 


to the publication IBM System/360 Operating 
System: System Control Blocks). 


Unit Assignment Table 


The unit assignment table (IHCUATBL) 
resides on the FORTRAN system likrary 
(SYS1.FORTLIB). Its size depends on the 
Maximum number of units that can be 
referred to during execution of any FORTRAN 
load module. This number (299) is speci- 
fied ky the user during the system genera- 
tion process via the FCRTLIB macro 
instruction. 


The unit assignment table is designed to 
be used by both IHCFIOSH and IHCDIOSH. It 
is included once, by the linkage editor, in 
the FORTRAN load module as a result of an 
external reference to it within IHCFIOSH 
and/or IHCDIOSH. 


The unit assignment table contains a 
16-byte entry for each of the unit numbers 
that can be referred to by either IHCDIOSH 
or IHCFIOSH. These entries differ in for- 
mat depending on whether the unit has keen 
defined as a direct accesSs or aS a sequen- 
tial access data set. Because IHCDICSH 
deals only with direct access data sets, 
only the entry for a direct access unit is 
Shown here. (Refer to the IHCFIOSH section 
"Table and Blocks Used", for the format of 
the unit assignment table as a whole.) If 
IHCDIOSH encounters a reference to a 
sequential access data set, it is consider- 
ed aS an error, and control is passed to 
the load module termination routine of 
IHCFCOMH. 


Figure 61 illustrates the unit assign- 
ment table entry format for a direct access 
data set. 


or me ea ee SA cee |e Se ey See Sees | Se ee See, Se a ee rs en a coe ee en ee ee ae ee ee ee ; 
| Pointer to unit block xx 


1 

| (UBLOCKxx) | 

}-—--——__-------------—----_-__- + 
| Default values for DSRNxx (only |8 Lytes| 

| applies to sequential access | 

| data sets -- not used by | 

| IHCDIOSH) | 

+ 

| 

| 


| Pointer to parameter 1listxx 
| (LISTxx) 


UBLOCKxx is the unit block generated 
for unit number xx. 


DSRNxx is the unit number for the 
direct access data set (xx299). 


LISTxx is the parameter list that 
defines the direct access data set 
associated with unit number xx. 
Figure 61. Unit Assignment Table Entry for 
a Direct Access Data Set 


| 
| 
| 
| 
| 
| 
| 
| 
| 
m | 


The pointers to the unit blocks are 
inserted into the unit assignment table 
entries by IHCDIOSH when the unit Llocks 
are constructed. 


The pointers to the parameter lists are 
inserted into the unit assignment takle 
entries by IHCDIOSH when IHCDIOSH receives 
control from the initialization section of 
the FORTRAN load module being executed. 
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BUFFERING 


All direct access input/output opera- 
tions are double-buffered. (The doukle 
buffering schere may be overridden ky the 
user if he specifies in his DD statements: 
BUFNC=1.) This implies that during data 
control block opening, two buffers will be 
oktained for each data set. The addresses 
of these buffers are given alternately to 
IHCFCOMH as rfointers to: 


e Buffers to be filled in the case of 
output. 


e Data that has been read in and is to ke 
rrocessed in the case of input. 


Each buffer has its own DECB. This 
increases I/O efficiency by overlapping of 
I/O operations. 


CCMMUNICATION WITH THE CONTRCL PROGRAM 


In requesting services of the control 
program BSAM and BDAM routines, IHCDIOSH 
uses L and E forms of S-type macro instruc- 
tions (refer to the publication IBM Syster/ 


360 Creerating System: Supervisor and Data 
Management Macro Instructions). 


CPERATION 


The processing of IHCDIOSH is divided 
into five sections: file definition, file 
initialization, read, write, and termina- 
tion. When a section receives control, it 
performs its functions and then returns 
control to the caller (either the FORTRAN 
load module or IHCFCOMH). 


File Definition Section 


The file definition section is entered 
from the FORTRAN load module, viaa 
compiler-generated calling sequence, if a 
DEFINE FILE statement is included in the 
FCRTRAN source module. The file definition 
section performs the following functions: 


e Checks for the redefinition of each 
direct access unit number. 


e Enters the address of each direct 
access unit number's parameter list 
into the appropriate unit assignment 
table entry. 


e Estaklishes addressability for IHCDICSH 
Within IHCFCOMH. 


Each direct access unit number appearing 
in a DEFINE FILE statement is checked to 
see if it has been defined previously. If 
it has been defined previously, the current 
definition is ignored. If it has not been 
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defined previously, the address of its 
parameter list (i.e., the definition of the 
unit number) is inserted into the proper 
entry in the unit assignment table. The 
next unit number if any is then obtained. 


When the last unit number has been pro- 
cessed in the above manner, the file 
definition section stores the address of 
IHCDIOSH into the FDIOCS field within IHCF- 
COMH. This enables IHCFCOMH to link to 
IHCDICSH when IHCFCOMH encounters a direct 
access I/O statement. Control is then 
returned to the FORTRAN load module to con- 
tinue normal processing. 


File Initialization Section 


The file initialization section receives 
control from IHCFCOMH whenever input or 
output is requested for a direct access 
data set. The processing performed ky the 
initialization section depends on whether 
an I/O operation was previously requested 
for the data set. 


NO PREVIOUS OPERATION: If no operation was 
previously requested for the data set spe- 
cified in the current I/O request, the file 
initialization section first constructs a 
unit block for the data set. (The GETMAIN 
macro instruction is used to obtain the 
main storage for the unit biock.) The 
address of the unit block is inserted into 
the appropriate entry in the unit assign- 
ment table. 


The file initialization section then 
reads the JFCB (job file control block) via 
the RDJFCB macro instruction. The value in 
the BUFNO field of the JFCB is inserted 
into the DCB skeleton in the unit block. 
This value indicates the number of buffers 
that are obtained for this data set when 
its data control block is opened. If the 
BUFNC field is null (i.e., if the user did 
not include the BUFNO subparameter in the 
DD statement for this data set), or other 
than 1 or 2, the file initialization sec- 
tion inserts a value of two into the DCB 
Skeleton. 


The file initialization section next 
examines the JFCBIND2 field in the JFCB to 
determine if the data set specified in the 
current I/O request exists. If the 
JFCBIND2 field indicates that the specified 
data set does not exist, and if the current 
request iS a write, a new data set is 
created. (If the current request is a 
read, an error iS indicated and control is 
returned to IHCFCOMH to terminate load 
module execution. If the current request 
is a find, the request is ignored, and con- 
trol is returned to IHCFCOMH.) If the 
JFCBIND2 fieid indicates that the specified 
data set already exists, a new data set is 
not created. The file initialization sec- 
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tion processing for a data set to be 
created, and for a data set that already 
exists is discussed in the following 
paragraphs. 


Data Set to ke Created: The data control 
klock for the new data set is first opened 


for the BSAM, load mode, WRITE macro 


instruction. The BSAM WRITE macro instruc- 
tion is used to create a new data set 
according to the format specified in the 
parameter list for the data set in a DEFINE 
FILE staterent. The data control block is 
then closed. Subsequent file initializa- 
tion section processing after creating the 
new data set is the same as that described 
for a data set that already exists (refer 
to the section “Data Set Already Exists"). 


Data Set Already Exists: The data contrel 
block for the data set is opened for direct 


access processing by the BDAM routines. 
After the data control block is opened, the 
file initialization section fills in 
various fields in the unit Elock: 


e The number of records in the data set 
is inserted into the RECNUM field. 


e The address of the DECB skeletons 
(DECBA and DECBB) are inserted into the 
CURBUF and the NXTBUF fields, 
respectively. 


e The addresses of the I/C kuffers 
obtained during data control block 
opening are inserted into the aprprorpri- 
ate DECRB skeletons. 


e The address of the BLKREFA and the 
ELKREFB fields in the unit block are 
inserted into the appropriate DECB 
skeletons. 


Note: If the user specifies BUFNO=1 in the 
DD statement for this data set, only one 
I/O buffer is obtained during data control 
klock opening. In this case, the NXTBUF 
field, the BLKREFB field, and the DECBB 
Skeleton are not used. 





Subsequent file initialization section 
processing for the case of no previous 
Operation depends upon the nature of the 
I/C request (find, read, or write). This 
processing is the same as that -described 
for the case of a previous operation (refer 
to the secticn “Previous Operation"). 


PREVICUS CPERATION: If an operation was 
previously requested for the data set sre- 
cified in the current I/O request, the file 
initialization section processing depends 
upon the nature of the current I/O request. 


If the current request is either a find 
or a read, control is passed to the read 
section. 


If the current request is a write, con- 
trol is passed to the secondary entry in 
the write section. 


Read Section 


The read section of IHCDIOSH processes 
read and find requests. The read section 
may be entered either from the file ini- 
tialization section of IHCDIOSH, or from 
IHCFCOMH. In either case, the processing 
performed is the same. In procesSing read 
and find reguests, the read section fer- 
forms the following functions: 


e Reads physical records into the buffer 
(Ss) obtained during data control block 
opening. 


e Makes the contents of these buffers 
available to IHCFCOMH for processing. 


e Updates the associated variable that is 
defined in the DEFINE FILE statement 
for the data set. 


The read section, upon receiving con- 
trol, first checks to see if the record to 
be found or read is already in an I/O buff- 
er. Subsequent read section processing 
depends upon whether the record is in the 
buffer. 


RECORD IN BUFFER: If a record is in the 
buffer, the read section determines whether 
the current request is a find or a read. 


If the current request is a find, the 
associated variable for the data set is 
updated so that it points to the relative 
position within the direct access data set 
of the record that is in the buffer. Con- 
trol is then returned to IHCFCOMH. 


If the current request iS a read, the 
read operation that read the record into 
the buffer is checked for completion. The 
read section then places the address of the 
buffer and the size of the buffer into 
registers for use by IHCFCOMH. The asso- 
ciated variable for the data set is updated 
so that it points to the reiative position 
within the direct access data set of the 
record following the record just read. 
Control is then returned to THCFCOMH. 


RECORD NOT IN BUFFER: If a record is not 
in the buffer, the read section first 
obtains the address of the buffer to be 
used for the current request. The relative 
record number of the record to be read is 
then inserted into the appropriate BLKREF 
field in the unit block (1.e., BLKREFA or 
BLKREFB). The proper record is then read 
from the specified data set into the buff- 
er. Subsequent read section processing for 
the case of a record not in the buffer is 
the same as that described for a record in 
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PROCESSING IF ENTERED FROM IHCFCCMH: 


the buffer 
Buffer"). 


(refer to the section “Record In 


Note 1: Record retrieval can proceed con- 
currently with CPU processing only if the 
user alternates FIND statements with READ 
Statements in his program. 


Note’2: If an I/O error occurs during 
reading, the control prograr returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSH. The SYNADR rou- 
tine sets a switch to indicate that an I/O 
error haS occurred, and then returns con- 
trol to the control program. The control 
program completes its processing and 
returns control to IHCDIOSH. IHCDIOSH 
interrogates the switch, finds it to be 
set, and passes control to the I/O error 
routine of IHCFCOMH. 





Write Section 


The write section of IHCDICSH processes 
write requests. The write secticn may be 
entered either from the file initialization 
section of IHCDIOSH, or from IHCFCOMH. The 
processing performed by the write section 
depends upon where it is entered from. 


PRCCESSING IF ENTERED FROM FILE INITIALIZA- 
TICN SECTICN: If the write section is 
entered from the file initialization sec- 
tion of IHCDIOSH, no writing is performed. 
The write section only provides IHCFCOMH 
with ktuffer space in which to place the 
record to be written. The relative record 
number of the record to be written is 
inserted into the appropriate BLKREF field 
(i1.e., BLKREFA or BLKREFB) . (The record is 
written the next time the write section is 
entered.) For a formatted write, the buff- 
er is filled with blanks. For an unfor- 
Matted write, the buffer is filled with 
zeros. The write section then places the 
address of the buffer and the size of the 
kuffer into registers for use by IHCFCOMH. 
Control is then returned to IHCFCOMH. 


Each 
time the write section is entered from 
IHCFCOME, it writes the contents of the 
bkuffer onto the specified data set. Subse- 
quent write section processing for 
entrances from IHCFCOMH is the same as that 
described for entrances from the file 
initialization section of IHCDIOSH (refer 
to “Processing If Entered From File Initia- 
lization Section"). In addition, the asso- 
ciated variable is modified prior to 
returning to IHCFCOMH. The associated 
variakle for the data set is updated so 
that it points to the relative position 
within the direct access data set of the 
record following the record just written. 
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Note 1: The writing of physical records by 
this section is overlapped. That is, while 
IHCFCOMH is filling buffer A, buffer Bis 
being written onto the output data set. 
When buffer A has been filled, the write 
from buffer B is checked for completion. 
Upon completion of the write operation, 
IHCFCOMH starts placing data into buffer B. 
In addition, a write from buffer A is 
initiated. 


Note 2: If an I/O error occurs during 
writing, the control program returns con- 
trol to the synchronous exit routine 
(SYNADR) within IHCDIOSH. The SYNADR rou- 
tine sets a switch to indicate that an I/O 
error has occurred, and then returns con- 
trol to the control program. The control 
program completes its processing and 
returns control to IHCDIOSH. IHCDIOSH 
interrogates the switch, finds it to be 
set, and passes control to the I/O error 
routine of IHCFCOMH. 


Termination Section 


The termination section of IHCDIOSH 
receives control from the load module ter- 
mination routine of IHCFCOMH. The function 
of this section is to terminate any pending 
I/O operations involving direct access data 
sets. The unit blocks associated with the 
direct access data setS are examined by 
IHCDIOSH to determine if any I/O is pend- 
ing. CHECK macro instructions are issued 
for all pending I/O operations to insure 
their completion. 


The data control blocks for the direct 
access data sets are closed, and the main 
storage occupied by the unit blocks is 
freed via the FREEMAIN macro instruction. 
Control is then returned to the load module 


termination routine of IHCFCOMH to complete 


the termination process. 


ITHCIBERH 


ITHCIBERH, a member of the FORTRAN system 
library (SYS1.FORTLIB) , processes object- 
time source statement errors. IHCIBERH is 
entered when an internal statement number 
(ISN) cannot be executed because of a 
source statement error. 


The ISN of the invalid source statement 
is obtained (from information in the cal- 
ling sequence) and is then converted to 
decimal form. IHCIBERH then links to IHCF- 
COMH to implement the writing of the fol- 
lowing error message: 


IHC230I - SOURCE ERROR AT ISN 


XXXX - EXECUTION FAILED SUBROU- 
TINE (name) 
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After the error message is written on 
the user-designated error output data set, 
IHCIBERH passes control to the IBEXIT rou- 
tine of IHCFCOMH to terminate execution. 


Chart 30 illustrates the overall logic 
of IHCIBERR. 


IHCDEUG 


IHCDBUG performs the object-time opera- 
tions of the Debug Facility statements. 
Ali linkages from the load module to IHCD- 
BUG are compiler generated. 


Items and Buffer 


The fcllowing items in IHCDBUG are 
initialized to zero at load time: 


CSRN - the data set reference number 
TRACFLAG - trace flag 

IOFLAG - input/output in progress flag 
DATATYPE - variable type bits 


Whenever information is assembled for 
output, it is placed in a 70-byte area 
called DBUFFER. The first character of 
this area is permanently set to blank, for 
Single spacing. 


Cperation 


The first portion of IHCDBUG, called by 
entry name DEBUG#, is a transfer table; 
this table is referred to by the code 
generated for the Debug Facility state- 
ments, and kranches to the thirteen section 
of IHCDBUG. These sections are discussed 
individually. 


TRACE ENTRY: If TRACFLAG is off, this rou- 
tine exits. Otherwise, the characters 
"TRACE are moved to DBUFFER + 1, the subk- 
routine OCUTINT converts the statement label 
to EBCDIC and places it in DBUFFER, and a 
branch is made to OUTBUFFR. 


SUBTRACE ENTRY: The characters ‘SUBTRACE'S 
and the name of the program or subprograr 
are moved to DBUFFER and a branch to OUT- 
BUFFR is made. 


SUBTRACE RETURN ENTRY: The characters 
*"SUBTRACE *RETURN** are moved to DBUFFER 
and a branch to OUTBUFFR takes place. 


UNIT ENTRY: The unit number argument is 
placed in DSRN and the routine exits. 


INIT SCALAR ENTRY: The data type is saved, 
the location of the scalar is computed, 
subroutine OUTNAME places the name of the 
scalar in DBUFFER, and a branch is made to 
CUTITEM. 


INIT ARRAY ELEMENT ENTRY: This routine 
saves the data type, computes the location 
of the array element, and (via the subrou- 
tine OUTNAME) flaces the name of the array 
in DBUFFER. It then computes the element 
number as follows: 


element number = 
array location) 


((element location - first 
/ element size) + 1 


and places a left parenthesis, the element 
number (converted to EBCDIC by subroutine 
OUTINT) , and a right parenthesis in DBUFFER 
following the array name. A branch is then 
made to OUTITEM. 


INIT FULL ARRAY ENTRY: If IOFLAG is on, 
the character X‘'FF' is placed in DBUFFER, 
followed by the address of the argument 
list, and a branch is made to CUTBUFFR. 
Otherwise, a call to the INIT ARRAY ELEMENT 
entry is constructed, and the routine loops 
through that call until all elements of the 
array have been processed, when it exits. 


SUBSCRIPT CHECK ENTRY: The location of the 
array element iS computed; if it is less 
than or equal to the maximum array loca- 
tion, the routine exits. If the array ele- 
ment location is outside the bounds of the 
array, the element number is computed and 
the characters ‘SUBCHK' are placed in 
DBUFFER. The subroutine OUTNAME then 
places the name of the array in DBUFFER, 
OUTINT supplies the EBCDIC code for the 
element number (which is enclosed in paren- 
theses), and a branch is made to OUTBUFFR. 
TRACE CN ENTRY: TRACFLAG iS turned on (set 
to nonzero) and the routine exits. 


TRACE CFF ENTRY: TRACFLAG is turned off 
(set to zero) and the routine exits. 


DISPLAY ENTRY: If ILOFLAG is on, the chara- 
cters ‘DISPLAY DURING I/O SKIPPED‘ are 
moved to DBUFFER and a branch is made to 
OUTBUFFR. Otherwise, a calling sequence 
for the NAMELIST write routine iS con- 
Structed. If DSRN is equal to zero, the 
unit number for SYSOUT (in IHCUATBL + 6) is 
used as the unit passed to the NAMELIST 
write routine. On return from the NAMELIST 
write, this routine exits. 





START I/O ENTRY: The BYTECNT is set to 252 
to indicate that the current area is full, 
the IOFLAG is set to X‘'80' to indicate that 
input/output iS in progress, the CURBYTLC 
is set to the address of SAVESTRT (where 
the location of the first main -E-lock will 
be - refer to the description of ALLOCHAR), 
and the routine exits. 


END I/O ENTRY: The IOFLAG is saved in TEM- 
PFLAG and IOFLAG is reset to zero so that 
this section may make debug calls which 
result in output to a device. If no infor- 
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mation was saved during the input/output, 
this routine exits. 


The sukroutine FREECHAR is used to 
extract one character at a time from the 
Save area. If an X'FF' is encountered 
(indicating the output cf a full array), 
the next three bytes give the address of 
the call to INIT FULL ARRAY entry. A call 
to the DERUG INIT FULL ARRAY entry is then 
constructed and executed. If X'FFS is not 
encountered, characters are flaced in 
DBUFFER until an X'15' is found, indicating 
the end of a line. When this code is 
found, the subroutine CUTPUT is used to 
write out the line. 


If no main storage or insufficient main 
Storage was available for saving informa- 
tion during the input/output, the charac- 
ters "SOME DEBUG OUTPUT MISSING are placed 
in DRUFFER after all saved information (if 
any) has reen written out. The sukroutine 
CUTPUT is then uSed to write out the mes- 
sage, and this routine returns to the 
caller. 


Subroutines 
The fcllowing subroutines are used by 
the routines in IHCDBUG. 


CUTITEM: First, the characters ' = ‘ are 
moved to DBUFFER. The routine then loads 
the data to be output into registers. A 
bkranch on tyre then takes place. For fixed 
point, the routine OUTINT converts the 
value to FRBCLCIC and places it in DBUFFER. 

A kranch to CUTBUFFR then takes rlace. 


For floating values, subroutine OUTFLCAT 
places the value in DBUFFER. A kEranch tc 
CUTBUFFR then takes place. 


For corplex values, two calls to CUT- 
FLCAT are made -- first with the real part, 
then with the imaginary part. A left 
parenthesis is placed in DBUFFER before the 
first call, a comma after the first call, 
and a right parenthesis after the second 
call. A kranch to OUTBUFFR then takes 
place. 


For logical values, aT is placed in 
DBUFFFR if the value was nonzero; otherwise 
an F is placed in DBUFFER. A kEranch to 
CUTBUFFR then takes place. 


CUTNAME: This is a closed subroutine. Uf 
to six characters of the name are pclaced in 
DBUFFER. However, the first blank in the 
name causes the routine to exit. 


CUTINT: This is a closed subroutine. If 
the value (passed in R2) is equal to zero, 
the character ‘0Q' is placed in DBUFFER and 
the routine exits. If it is less than 
zero, a rinus sign is placed in DBUFFER. 
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The value is then converted to EBCDIC and 
placed in DBUFFER with leading zeros sup- 
pressed. The routine then exits. 


OUTFLOAT: This is a closed subroutine. [If 
the value iS zero, the characters '0.0E+00'° 
or '0.0D+00' are placed in DBUFFER, depend- 
ing upon whether the value is Single or 
double-precision, respectively, and the 
routine exits. If the values are less than 
zero, a minus sign is placed in DBUFFER. 
The floating number is then converted to a 
string of decimal EBCDIC characters anda 
power of ten by exactly the same aigorithm 
used in IHCFCUTH (this assures identical 
results). 








Let: x = 8 for single-precision, 
x = 17 for double-precision. 
If 12|value|]<10 , it is output to the 


CBUFFER in Fx+1.x-n format where n is 
the integer portion of log |value|. 


Otherwise it iS output in G x+5.x format. 
The routine then exits. 


OUTBUFFR: .If IOFLAG is not set, the rou- 
tine calls the subroutine CUTPUT and then 
exits. Otherwise, IOFLAG is set to indic- 
ate that debug output during input/output 
occurred. Then, a call is made to ALLOCHAR 
for each character in DBUFFER, and finally, 
a call to ALLOCHAR with X‘'15' indicating 
the end of the line. The routine then 
exits. 


ALLOCHAR: This is a closed sukroutine. If 
BYTECNT is equal to 252, indicating the 
current block is full, a new klock of 256 
bytes is obtained by a GETMAIN macro. If 
no storage was available, an X‘'0O7', indi- 
cating end of core, is placed in the last 
available byte position, IOFLAG is set to 
full, and the routine exits. Otherwise, 
the address of the new block is placed in 
the last three bytes of the previous Llock, 
preceded by X'37" indicating end of -Llock 
With new block to follow. CURBYTLC is then 
set to the address of the new block and 
BYTECNT is set to zero. The character 
passed as an argument is then prlaced in the 
byte pointed to by CURBYTLC, one is added 
to both CURBYTLC and BYTECNT, and the rou- 
tine exits. 


FREECHAR: This is a closed subroutine. If 
the current character extracted is X'37', 
the next three bytes are placed in CURBYTLC 
and the current block is freed. If the 
current character is X‘'O7' the block is 
freed and a branch to the End I/O exit is 
taken. Otherwise, the current character is 


190 


passed to the calling routine and CURBYTLC 
is incremented by 1. 

CUTPUT: This is a closed subroutine. If 
DSRN is zero, the SYSOUT unit number is 
oktained from IHCUATBL + 6. A call is then 
made to FIOCS# output initialize, DBUFFER 
is transferred to the FIOCS# lcuffer, anda 
call is made to FIOCS# output. The routine 
then exits. 


IHCTRCH 


IHCTRCH, a member of the FCRTRAN system 
likrary (SYS1.FCRTLIB) processes terminal 
errors detected cy FORTRAN library subrou- 
tines at object time. IHCTRCH is entered 
only from the IBFERR routine within IBCF- 
CCMH. IBFERR consists only of a call to 
ITHCTRCH. 


IHCTRCH issues the following message: 


THCxxxI 


TRACEBACK FOLLOWS ROUTINE ISN REG. 14 
where xxx is the error code (in decimal 
form) that it oktains from the calling 


sequence. 


If the error occurred in IHCFCOMH, 
IHCFCVTH, IHCNAMEL, IHCDIOSE, or IHCFIOSH, 
IHCTRCH setsS up an area which can ke pro- 
cessed aS a Standard save area for the 
first traceback line. 


For each tracekack line, IHCTRCH gets 
the name of the called routine, the inter- 
nal staterent number, if any, of the call 
Within the calling routine, and the con- 
tents of register 14, in hexadecimal. 


After printing each line, IHCTRCH checks 
whether the called routine was the rain 
FORTRAN routine. If so, it prints the 
entry point, in hexadecimal, and branches 
to IBEXIT. If not, it enters a tracebkack 
lcoop-check routine, which builds and checks 
a takle of save area addresses. If the 
table is full or if a loop is detected, 
IHCTRCH prints TRACEBACK TERMINATED and 
then prints the main FORTRAN routine entry 
point and branches to IBEXIT. 


IHCTRCH uses IHCFCVTH to convert to 
printable hexadecimal format and it uses 
IHCFICSH for printing. 


Further information about traceback 
including an example of output is contained 


in the publication IBM System/360 Operating 
System: FORTRAN IV (H) Programmer's Guide. 
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Chart 24. Implementation of READ/WRITE/FIND Source Statements 
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Chart 25. 
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Table 36. IHCFCOMH Subroutine Directory 


Paubroueune) Function | 
|----------}~---------------------------------- == --- +--+ 5-5 == -- == { 
| EXCEPT [Checks for presence of END= parameter, and passes control to the load rodule| 
| {if present. | 
| FENDF |Closing section for a READ or WRITE requiring a format. | 
| FENDN {Closing section for a READ or WRITE not requiring a format. | 
| FEOFM Jimplements the END FILE source statement. | | 
| FERROR |Checks for the presence of the ERR= farameter, and passes control to the | 
| | load module if present. | 
| FICAF {I/C list section for list array cf a READ or WRITE requiring a format. | 
| FICAN {I/O list section for list array of a READ cr WRITE not requiring a format. | 
| FIOLF {I/O list section for a 11st variakle of a READ or WRITE requiring a format. | 
| FIOLN {I/C list section for a 11st variable of a READ or WRITE not requiring a | 
| | format. | 
| FPAUS {Implements the PAUSE source statement. | 
| FRDNF {Opening section of a READ not requiring a format. | 
| FRDWF {Opening section of a READ requiring a format. | 
| FRWND |Implements the REWIND source statement. | 
| FSTCP |Iimplements the STOP source statement. | 
| FWRNF |Opening section for WRITE not requiring a format. | 
| FWRWE {Opening section for WRITE requiring a format. | 
| IBEXIT |Closes all data sets and terminates execution. | 
| IBFERR |Calls ICHTRCH to process terminal object-timre errors. | 
| IBFINT |Processes program interruptions. | 
| FBKSP pen EEe went the BACKSPACE source statement. | 
Ds ah Sh Sa ne th a ce aa a eS IN 4 
Table 37. IHCFCVTH Subroutine Directory 

ck a at IN ag OR a a In a a a a te 3 
Subroutine Function | 
|----~-----4------------------------------------------~--------------------------------- { 
| FCVAL |Reads alphameric data. | 
{| FCVAO {Writes alphameric data. | 
| FCVCI {Reads complex data. | 
{| FCVCO {Writes complex data. | 
{| FCVDI {Reads double precision data with an external expcnent. | 
| FCVDO jWrites double precision data with an external exponent. | 
| FCVEI {Reads real data with an external exponent. | 
| FCVEO {Writes real data with an external exfonent. | 
| FCVFI {Reads real data without an external exponent. | 
| FCVFO {Writes real data without an external exponent. | 
| FCVGI {Reads general type data. | 
| FCVGO j|Writes general type data. | 
| FCVIIL |Reads integer data. | 
| FCVIO {Writes integer data. | 
| FCVLI {Reads logical data. | 
| . FCVLO {Writes logical data. | 
| FCVZI {Reads hexadecimal data. | 
| FCVZO {Writes hexadecimal data. | 
eae eee aE a aT en ces a aa ach a a a a J 
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Chart 29. IHCDIOSH Overail Logic - File Initialization, Read, Write, and Termination 
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IHCFIOSH Routine Directory 
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(=. a ca aA aaa aa a a Rm a 1 
| Routine | Function | 
a aN a a aa 
|FCLCS {CHECKS double-buffered output data sets. | 

| | 

| FCNTL |Services device manipulation requests. | 
| | | 
|FINIT [Initializes unit and data set. | 
| | | 

| FREAD |Services read requests. | 
| | | 
|FRITE |Services write requests. | 

ReMi epee ee Bare Sa Aaa ae a a at SN ae os 4 

Table 39. IHCDIOSH Routine Directory 
PS a: Ute ae SS TT cae GE ge OTe eae Ve Ce ea ae PR Be ee eg Te Gee ee Age 1 
{| Routine | Function | 
|---------- }--------------------—------ ~~~ --- === + ---- 5 =~ $= === +--+ === - { 
| DASDEF | Processes DEFINE FILE statements: enters address of parameter lists into | 
| | junit assignment table, checks for redefinition of direct access unit num- | 
| |bers, and establishes addressakility for IHCDIOSH within IHCFCOMH. | 
| | | 
|DASINIT |Constructs unit blocks for nonopened direct access data sets, creates and | 
| | formats new direct access data sets, and opens data control blocks for | 
| |direct access data sets. | 
| | | 
| DASREAD |Reads physical records, passes Luffer pointers and buffer size to IHCFCOMH, | 
| {and updates the associated variable. | 
| | 
| DASTERM {Checks pending I/O operations, closes direct access data sets, and frees | 
| Jmain storage occupied by unit Elocks. | 
| | | 
|DASTRA |Determines operation type and transfers control to appropriate routine. | 
| | | | 
|DASWRITE |Writes physical records, provides IHCFCOMH with buffer space, and updates | 
| Jthe associated variable. | 
ieee a a a A ie a ea ee ak et J 
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Chart 30. IHCIBERH Overall Logic 
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APPENDIX F: 


Data references in the form of suk- 
Scripted variable expressions in FORTRAN 
are converted into object code that 
includes address arithmetic and indexed 
references to main storage addresses. 

Since the conversion involves all phases of 
the compiler, a summary of the method is 
given here. 


Consider an array A of n dimensions 
whose element length is L, and whose dimen- 
Sions are Dl, D2, D3, ..--,Dn. If Such an 
array iS assigned main storage starting at 
the address P11, then the element A(J1, J2, 
J3,<«-e-,Un) is located at 
P = P11 + (31-1) *L + (J2-1) #D1*L + 
(J3-1) *D1*D2*L + «2. + (Jn-1) *D1*D2*D3* 
~2-*D (n-1) *L 


This may be expressed as: 
P = POO + J1¥*L + J2*(DI*L) + J3* (D1*#D2*L) 
+ oo. + In* (D1*D2*D3* .2. *D(n-1) *L) 


where 


POO = P11 - (L#D1*L + D1*#D2*L + ... + 
D1*D2* ... *D(n-1) *L) 


For fixed dimensioned arrays, the quan- 
tities DI*L, D1*D2*L, D1*D2*D3*L, ... ; 
which are referred to as dimensicn factors, 
are computed at compile time. The sum of 
these quantities, which is referred to as 
the span of the array, is also computed at 
compile time. (Phase 15 aSSignS an array a 
relative address equal to its actual rela- 
tive address minus the span of the array.) 


In the object code, P is finally formed 
as the sum of a base register, an index 
register, and a displacement. The phase 15 
segment CORAL associates an address con- 
Stant with each fixed dimensioned array 
such that Pa2PO002>Pat4095, wnere Pa is the 
address inserted into the address constant 
at program fetch time. The effective 
address is then formed using a kase regis- 
ter containing the address constant, a dis- 
placement equal to P00 - Pa, and an index 
register, which contains the result of a 
computation of the form: 


L 2,01 

SLL 2 ,logeaL 

L 1,52 

M 0,L*D1 

AR 2,1 

L 1,Jd3 

M 0,D1*D2*L 
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ADDRESS CCMPUTATICN FOR ARRAY ELEMENTS 


AR Pea | 

L 1,0n 

M Q0,01*D2*...*D (n-1) 
AR 2,1 


Absorption of Constants in Sukscrirt 
Expressions 


Sukscript expressions may include con- 
Stant parts whose contribution to the final 
effective address is computed at compile 
time. For example, 


B (I-2,3+4, 3*5- (L+7) -6) 


would usually ke treated in such a way that 
the effect of the 2, the 4, and the 6 would 
ke absorbed into the displacement at com- 
pile time. 


Consider an example of the form 
A(J1+*K1,J32+K2, .~.. ,JntKn) , 
where A is a fixed dimensioned array and 


K1, K2, , Kn are integer constants. 
Phase 15 will insert the quantity 


K1*L + K2* (D1*L) + K3* (D1*D2*L) + 
eee + Kn (D1*D2* 2... *D(n-1) *L) 

into the displacement (DP) field of the 
corresponding subscript or load address 
text entry. The constants will not other- 
wise ke included in the subscript expres- 
Sion. When phase 25 generates machine 
code, the contents of the DP field are 
added to the displacement. To ensure that 
the resultant expression lies within the 
range of 0 to 4095, phase 20 performs a 
check. If the result is not in the range, 
a dictionary entry is reserved for the 
result of the addition, and a suitable add 
text entry is inserted to alter the index 
register immediately before the reference. 


Arrays as Parameters 


When an array iS used aS an argument, 
the location of its first element, P11, is 
passed in the parameter list. The prologue 
of the called subroutine contains machine 
code to compute the corresponding P00 loca- 
tion. When an array has variable dimen- 
Sions, no constant absorption takes place 
and the dimension factors are computed for 
each reference to the array. 
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APPENDIX G: CCMPILER STRUCTURE 


The FORTRAN (H) compiler is structured 
in a planned overlay fashion. A planned 
overlay structure is a single load module, 
created by the linkage editor in response 
to overlay control statements. These 
statements, a description of the planned 


overlay structure, and instructions in spe- 


cifying such a program structure are pre- 
sented in the publication IBM System/360 
Operating System: Linkage Editor. The 
processing performed by the linkage editor 
in response to overlay control statements 
is described in the publication IBM System/ 


360 Operating System: Linkage Editor, Pro- 
gram Logic Manual. 


The compiler's planned overlay structure 
consists of 13 segments, one of which is 
the root. The root segment contains the 
FSD and includes the processing units 
(e.g., the compile-time input/output rou- 
tines) and data areas (€.g., communication 
region) that are used by two or more 


phases. The root segment remains in main 
im) 
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*The number in parentheses times 1,000 equals the approximate segment length. 


®Figure 62. Compiler Overlay Structure 
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(41. 2) 


storage throughout the execution of the 
compiler. 7 


Each of the remaining 12 segments con- 
stitutes a phase or a major portion of a 
phase. Phase segments are overlaid as con- 
piler processing requires the services of 
another segment. 


Figure 62 illustrates the comrpiler's 
planned overlay structure. In the figure, 
each segment is identified by a number. 
Segments that originate from the same hori- 
zontal line overlay each other as needed. 
The figure also indicates the approximate 
Size (in bytes) of each segment. 


The longest path* of this structure is 
formed by segments 1, 4, and 5 kecause, 


<P <<a ae en cin cate ee A ee ae NOD RD ome ee ee a ee ee ee 


1A path consists of a segment, all segments 
between it and the root segment, and the 
root segment. 


7 - Phase 20 


(6) 


11 - Phase 20 
12 - Phase 30 


(9.6) (16.1) 


13 - Phase 25 


(56. 1) 


10 - Phase 20 


(47.6) 


when they are in main storage, the compiler Segment 2: This segment is phase 10. The 





requires approximately 81,000 bytes. Thus, origin of the segment is immediately after 
the minimum main storage requirement for segment 1. At the completion of phase 10 
the compiler is approximately 82,000 bytes. operation, segment 2 is overlaid ky segment 
3 if the XREF option was chosen or by seg- 
The linkage editor assigns the relocat- ment 4 if the option was not chosen. The 
able origin of the root segment (the origin composition of segment 2 is illustrated in 
of the compiler) at 0. The relocatakle Takle 42. 


origin of each segment is determined by 
summing the length of all segments in the 








path. For example, the origin of segment eTable 42. accent ~ 2 Compositicn 

10 is equal to the length of segment 1 piuS == ,;---------------+7--------------- - + 1 
the length of segment 4 plus the length of 1eontrol Seceioal Entry Point (s) | 
segment 7. -}---—-----------—- 4—~—-—-—~—~—--—-—-—-—~—-—-—~-—--—-—---—-~--- { 
| STALL-IEKGST | LEKGST | 
|XSUBPG-IFKCSR |IEKCSR | 
The segments that constitute each phase |LABTLU-IEKCLT |IEKCLT | 
of the compiler are outlined in Takle 40. |XARITH-IEKCAR |IEKCAR | 
The remainder of this appendix is devoted |DSPTCH-IEKCDP |IEKCDP,IEKCIN | 
to a discussion of the segments of the |XIOPST-IEKDIC |IEKDIC | 
| GETCD-IEKCGC | IEKAREAD, | 
| CSCRN-IEKCCR | LEKCCR, LEKCS3, 1EKCS1, | 
eTable 40. Phases and Their Segments | |} TIEKCS2, TIEKCLC | 
a a ep 1 |XTNDED-IFKCTN |IEKCTN | 
{Phase 1seqnent is) Constituting Phase | | LEKKCS {| LEKKOS | 
f——— ————— 4---—-—~-~-~—~—~—~—-—-—~—~——-———~—-—~-—~—~—-~—~—-—--—-- 4 | XICOP-IEKCIO | TLEKCIO | 
{Phase 10|Segment 2 | | PUTX-IEKCPX | [EKCPX | 
| XREF {Segment 3 | | XDATA-IEKCDT | LEKCDT | 
|Phase 15|Segments 4, 5, 6 | | GETWCD-LTEKCGW | LEKCGW | 
{Phase 20{Segments 4, 7, 8, 9, 10, 11 | |XCLASS-IEKDCL |IEKDCL | 
[Phase 25|Segment 13 | | FORMAT-IEKTFM |IEKTFM | 
| Phase Sy oes 12 | |XSPECS-IEKCSP |IEKCSP | 
}————---——-—1---—-~—~—-—-—--—-—~—-—-—~—-—-——~—-—~--—--—--—----- 4 | XGC-LEKCGO | LEKCGO | 
| Note: ee 4 1s loaded whenever | | XDO-IEKCCDO | TIEKCDC | 
{phases 15, 50, or 30 are loaded. It con-| | PH10-ILEKCAA | | 
{tains data areas used by 15 and 20. { ane | | 
Ba Ltn a ee at et OS = Vtg Bee oa eee 8 G2 ee ee J 

Segment 1: This segment is the root seg- Segment 3: This segment contains sukrou- 
ment of the compiler's planned overlay tine XREF-IEKXRF. Its origin is immediate- 


Structure. Segment 11s the FSD. It has a ly after segment 1. If the XREF option is 

relocatable origin at 0 and is not overlaid chosen, segment 3 overlays segrent 2. If 

by other compiler phases. The composition the XREF option is not selected, segment 3 

of segment 1 is illustrated in Table 41. is not used and segment 2 is overlaid by 
segment 4. 


eTable 41. Segment - 1 Composition Segment 4: This segment is considered a 
1 portion of koth phases 15 and 20. It con- 
| tains data areas used by both phases. 
4 Included in this segment are RMAJCR-IEKJA4, 
| CMAJCR-IEKJA2, the full register assignment 
| takles, and phase 15/20 work areas. The 
| origin of segment 4 is immediately after 
| segment 1. Segment 4 is overlaid by seg- 
| TEKATM | PHAZSS,PHASB,TST,PHASS, | ment 13 if abortive errors are not encoun- 
| | TSP, TOUT | tered during the processing of phases 10 
|DCLIST-IEKTDC |IEKTDC | and 15. The composition of segment 4 is 
| 
| 
| 
| 
| 
| 
| 
| 
| 
J 


CS en ree ae SF ee Se ee A REE SEES EE RENE SEED ED ENERGY TED SUAS AS ED SEED A ENS “EEE ED I ce <n 


f 

| IEKATB 

| IEKAAO1 | PAGEHEAD 
{ADCON-IEKAAD | 
|PUTOUT-IEKAPT |PUTOUT 


| AFIXPI-ITEKAFP |FIXPI illustrated in Table 43. 
|SYSTAB-ITEKTAB  |IEKTAB 


| TIEKAA00 | LEKAGC, ENDFILE, IEKAA9 

| LEKFICCS | FIOCS#,FIOCS eTakle 43. cic oe - 4 Composition 

| LEK FCOMH fIBCOM#,IBCOM  [ — geaeeeaa--- yp ++ + 
| TIEKTLOAD | IEKUSD, ESD, TXT, LEKTXT, {Control Section| Entry Point (s) | 
| |RLD, IEKURL, IEND, IEKUND }------—-~—------- 4—~——-------~---~—~-—-—----- | 
|ERCOM-IEKAER | |CMAJCR-IFKJA2 | | 
| TEKAAA | |RMAJOR-IEKJA4 | | 
peas in, Reena eee eas tera he Se eS ces bE ep hs Ba ee ee 
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Segment 5: This segment is a portion of 
phase 15. It contains subroutines that 
implement the PHAZ15 functions of that 
phase which are arithmetic translation, 
text blocking, and information gathering. 
The origin of segment 5 is immediately 
after segment 4. Segment 5 is overlaid by 
segment 6. The composition of Segment 5 is 
illustrated in Table 44. 


eTable 44. eae - 5 Composition 
a a aa a a ce ee ed hs a 
icontrel Section] Entry Point (s) | 
Ss Sl a a a a Se a | 
| IEKLTB | | 
| LOOKER-IEKLOK | 
|GENRTN-IEKJGR |IEKJGR | 
|FUNRDY-IEKJFU | IEKJFU | 
|CONSTV-LEKKCN | IEKKCN | 
|OP1CHK-IEKKOP |IEKKOP,IEKKNG | 
| SUBMULT-IEKKSM |IEKKSM | 
|PHAZ15-LEKJA | LEKJA | 
|BLTNFN-IEKJBF | IEKJBF | 
|STTEST-LIEKKST |IEKKST | 
|RELOPS-IEKKRE |IEKKRE | 
|FINISH-IEKJFI |IEKJFI | 
|DFUNCT-IEKJDF |IEKJDF,IEKKPR | 
| MATE-IEKLMA | TEKLMA | 
| ANDOR-LEKJAN | LEKJAN, IEKKNC | 
J|CPLTST-IEKJCP |IEKJCP,IEKJMO { 
|UNARY-IEKKUN  |IEKKUN, LEKKSW, IEKJEX | 
|DUMP15-IEKLER |IEKLER | 
| PAREN-LEKKPA | [EKKPA | 
| GENER-IEKLGN | LEKLGN | 
| ALTRAN-IEKJAL | ITEKJAL | 
|TXTLAB-IEKLAB |IEKLAB | 
| TXTREG-IEKLRG |IEKLRG | 
| SUBADD-IEKKSA |IEKKSA | 
ined IEKJA1 | | 
ies ener areca ee eee: Da oe ee ee 


Segment 6: This segment is a portion of 
phase 15. It contains the subroutines that 
implement the CORAL functions of the phase. 
The origin of segment 6 is immediately 
after segment 4. Segment 6 overlays seg- 
ment 5 and is overlaid by segment 7 if syn- 
tactical errors are not encountered Ly 
phases 10 and 15. If errors are present, 
segment 6 is overlaid by segment 12. The 
composition of segment 6 is illustrated in 
Table 45. 


eTable 45. aerate - 6 Composition 
RRL arama ey ET el eg EES ee eee oe a eae sae rc Te 
iControl Sectional enecy Point (s) | 
see pepe Seca Rene ey eer er eient! Kemeny See ey Ee Sea eee er Me eos ee 5 
|DFILE-IEKTDF  |IEKTDF | 
|NLIST-IEKTNL | IEKTNL | 
| CORAL-IEKGCR | LEKGCR | 
|NDATA-IEKGDA  |IEKGDA | 
| EOVAR-LEKGEV | LEKGEV | 
| LEKGCZ | LEKGCZ | 
|DATOUT-IEKTDT |IEKTDT | 
eee | | 
eee eee ie oe eee 


Segment 7: This segment is a portion of 
phase 20. It contains the controlling sub- 


routine of that phase, the loop selection 
routine, and a number of frequently used 
utility subroutines. The origin of segment 
7 is immediately after segment 4. Segment 
7 overlays segment 6 if source module 
errors are not encountered by phases 10 and 
15. If errors are encountered, segment 7 
overlays segment 12 after its processing is 
completed, only if errors encountered are 
not serious enough to cause deletion of the 
compilation. The composition cf segment 7 
is illustrated in Table 46. 


eTable 46. Segment - 7 Composition 


CS er ee CS ee ED TED ED REED NEED RE com EES eee ERED REED SEED “ED ORNS RD SND SERED CREE ES EI EY SnD 


me ee eee ee cee ee ee eee cee ee cee eee ee ee eee PE CN EY CD ED ED CEN SINE MERIDEN SENS CES EAD EES OED UTED GEN “SP EON IES ES EE SEND aie 


: 
| 
{ 
|LPSEL-IEKPLS  |IEKPLS 
| LEKARW | | 
|TARGET+IEKPT  |IEKPT l 
|GETDIK-IEKPGK |IEKPGK,IEKPGC,IEKPIV, l 
| [EKPFT, TOFL l 

| 

J 


| 
| LEKFOP [ 
es es eee eee aed es si as as Se ee eae 


Segment 8: This segment is a portion of 
phase 20. It consists of the sukroutines 
that determine (1) the back dominator, back 
target, and loor number of each source 
module biock, and (2) the busy-on-exit 
data. Segment 8 is executed only if the 
CPT=2 path through phase 20 is followed. 
The segment is executed only once and is 
overlaid ky segment 9. The origin of seg- 
ment 8 is inmediately after segment 7. The 
composition of segment 8 is illustrated in 
Table 47. 


eTakle 47. chai - 8 Composition 
eB cae She ea a aI gee 
iControl Section| Entry Point (s) { 
}-~~—~—~-~-—~--- ~~~ ~~~ 
| SRPRIZ-IEKQAA |IEKQAA, IEKQAB { 
| TOPC-IEKPO | LEKPO | 
| LEKPTB | IEKPTB | 
| BAKT-IEKPB | LEKPB | 
| BIZX-LEKPZ | LEKPZ 
| LEKPBL | | 
Seniesa es eeee eens ete ee iy) Peee anny ee Meg Se er hee ae eae ey eee eee ae J 
Segment 9: This segment is a portion of 
phase 20. It contains subroutines that 


perform common expression elimination and 
strength reduction as well as the major 
portion of the utility subroutines used 
during text optimization. Segnrent 9 is 
executed only if the OPT=2 path through 
phase 20 is specified. The origin of seg- 
ment 9 is immediately after segment 7. 
During the course of optimization, segment 
9 overlays segment 8 and is overlaid by 
segment 10 after all module loors have been 
text-optimized. The composition of segment 
9 is illustrated in Table 48. 


eTable 48. 


eee - 9 Composition 


| KORAN- LEKQKO 

| WRITEX-LEKOWT 
| CIRCLE-IEKQCL 
| PERFOR-IEKOPF 
| TYPLOC-IEKOTL 
| XSCAN-IEKQOXS 

| XPELIM-IEKQXM 
| MOVTEX-IEKOMT 
| CLASIF-IEKQCF 


| LEKQLO 
| LEKQWT 


| LEKQCL, 


| IEKOPF 


| LEKOTL, 
| LEKOXS, 


| LEKQXM 


| TEKOMT, 
| LEKOCF, 


IEKQF 


ITEKQIT 
ITEKQOYS, TEKQZS 


ITEKQDT 
ITEKQPX, TEKQMF 


: 
| 


| BACMOV-IEKQBM | IEKQBM 
|REDUCE-IEKQSR |IEKQSR 
| SUBSUM-IEKQSM | IEKQSM 
| Epes renee ny einem er Eee rae eee SION) LEER E Ame aem eee bey meE See an ae pari re fe ea ee eR OR 


segment 10: 
phase 20. 


This segment is a portion of 
It contains full register 


asSignment subroutines, the utility subrou- 
tines used by them, and the subroutine that 


calculates the size of each text block and 


determines which text blocks can be 
branched to via RX-format branch instruc- 


tions. 


The origin 


Segment 10 is executed in the opti- 
mized paths through phase 20. 
of segment 10 is immediately after segment 


7. The composition of segment 10 is illus- 
trated in Table 49. 


eTable 49. 


Segment - 10 Composition 


Ss a ee ore, eee a0ee quent Se ere <a cues cee ee ce ce ee ee ee ee Dee eee ome eee eee cee 


Se eee eee es ee ewes cee DED OD cE ED <coee ees ee ee come ee ED eee ED ere ED ee eR eee cD a RD ED ED AEE aR eS cy a GES aoe coe 


| BLS-IEKSBS 

| CXIMAG-IEKRCI 
| BKPAS-IEKRBP 
| GLOBAS-IEKRGB 
| FWDPS1-IEKRF1 
| LOC-IEKRL1 

| FCLT50-IEKRFL 
| STXTR-IEKRSX 
| FWD PAS-IEKRFP 
| SEARCH-IEKRS 
| REGAS-LEKRRG 
| FREE-IEKRFR 

| BKDMP- IEKRBK 


| LEKSBS 
| LEKRCI 
| IEKRBP 
| LEKRGB 
| LEKRF 1 


| 
| LEKRFL, 


| LEKRSX 
| LEKRFP 
| IEKRS 

| LEKRRG 
| LEKRFR 
| TEKRBK 


ITEKRRL, [EKRTF 


segment 11: 
phase 20. 


This segment is a portion of 
It consists of the subroutines 


that perform basic register assignment. 
Segment 11 is executed only in the OPT=0 
path through phase 20. 


ment 11 
segment 
ment in 
another 
tion of 
50. 


phase 20, 


The origin of seg- 


is immediately after segment 7. 
11 does not overlay any other seg- 
nor is it overlaid by 
segment in phase 20. 
segment 11 is illustrated in Table 


The composi- 


eTable 50. 


eTakle 51. 


eTakle 52. 


} 

| SSTAT-LEKRSS 
| TALL-IEKRLL 
| SPLRA~ IEKRSL 


Segment 12: 


| LEKRSS 
| LEKRLL 
| TERRSL 


This segment is phase 30. 


ee - 11 Composition 


The 


origin of segment 12 is immediately after 


segment 4. 


Segment 12 overlays segment 6 


if syntactical errors are encountered dur- 
ing the processing of phases 10 and 15. If 
the errors detected ky these phases are not 
serious enough to cause deletion of the 


compilation, 


Sing is completed, 


segment 12, 
is overlaid ky segment 


after its proces- 


7. The composition of segment 12 is illus- 
trated in Takle 51. 


+ 
| MSGWRT- IEKP31 
| LEKP30- -IEKP30 


ee = 


12 Composition 


~---—-------— $--—~—-—-------=~~---- ~~ + 
| TLEKP31 | 
| 

cas te ase as cas Bec ee ere wae ee ae ee ee STE 

This segment is phase 25. The 


Segment 13: 


origin of segment 13 is immediately after 


segment 1. 


Segment 13 overlays segment 4. 


The composition of segment 13 is illus- 
trated in Table 52. 


| MANGN2-IEKVM2 
| PACKER- LEKTPK 
| LABEL-IEKTLE 
| RETURN- IEKTRN 
| FNCALL-IEKVFN 
| GOTCKK- LEKWKK 
| LISTER-IEKTLS 
| STCPPR-IEKTSR 
| ENTRY-IEKTEN 
| CGNDTA- IEKWCN 
| BRLGL- ILEKVBL 
| L[OSUB-IEKTIS 
| PROLCG-IEKTPR 
| MAINGN-IEKTA 
| TNTXT-LEKVTN 
| L[OSUB2-IEKTIO 
| END- IEKUEN 

| EPILCG-IFKTEP 
| LEKGMP 

| ADMCGN-IEKVAD 
| TSTSET-IEKVTS 
| PLSGEN- IEKVPL 
| SUBGEN- IEKVSU 
} UNRGEN- ILEKVUN 
| BITNFP-IEKVFP 
| FAZ25- ITEKP25 


[ 
{ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
I 
! 
| 
& 
| 
| 
! 
| 
| 
| 
| 
| 
! 
| 
| 
| 
| 
| 
| 
| 
| 
! 
i 
| 
| 
| 
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| LEKVM2 
| LEKTPK 
| LEKTLB 
| LEKTRN 
| LEKVFN 
| IEKWKK 
| LEKTLS 
| LEKTSR 
| LEKTEN 


| 

| IEKVBL 
| IEKTIS 
| LEKTPR 
| IEKTA 
| LEKVTN 
| LEKTIO 
| LEKUEN 
| IEKTEP 


| 

| IEKVAD 
| IEKVTS 
| LEKVPL 
| LEKVSU 
| LEKVUN 
| IEKVFP 
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APPENDIX H: DIAGNOSTIC MESSAGES 


The messages produced by the compiler 
are explained in the publication IBM 


System/360 Operating System: FORTRAN IV 
(H) Programmer's Guide. Each message is 


identified by an associated number. The 
following table associates a message number 
with the phase and subroutine in which the 
corresponding message is generated. 


As part of its processing of errors, 
whenever the compiler encounters an error 
that is serious enough to cause deletion of 
a compilation, it prints out a value, mm, 
for the PHASE SWITCH (refer to Appendix C 


isa aera inci Voces re ee 
|Routine in which| Phase in whieh 


| 
| Message |message number |message number| 
| 


number |is generated {is generated | 
| YeKoo21 {xClASS-IERDCL =| OCS | 
re. ee ea 
eat eee 
Wenoge! ana aeKCAR,, | 


| | 
l | LABTLU-IEKCLT, | 
| |DSPTCH-IEKCDP, | 
| |XIOOP-IEKCIO, | 
| |XCLASS-IEKDCL | 


Caton eta, 
oe ee 
ear re ee 
erage | CORN teeccn, 
St a a eee ceo | PHASE 10 


f + 

{| IEKO12I |{CSORN-IEKCCR | 
Sessa fanaa aa 

| IEKO13I |XARITH-IEKCAR, | 

l | PUTX-IEKCPX, l 

| |CSORN-IEKCCR, | 

l |XCLASS-IEKDCL | 


pe-S=-===- | AES SRLSER eas | 
| IEKO14I |XDATYP-IEKCDT, | 
| |XSPECS-IEKCSP | 
(==Saeeeas encase ea aes { 
| IEKO161 |XGO-IEKCGO l 
=== | aS SSE RCS q 
| IEKO17I |XGO-IEKCGO l 
}------~--}---------------- 
| IEK019I |XGO-IEKCGO | 
[23s 2---— | Ea ie eae ares { 
| IEKO201 | XGO-LEKCGO l 
po eet ee eee OE ——-——~———-—-——-—~————— 


| IEKO21I oad IEKCGO _ | 


hems seRnSUGn SERINE. GOSHEN SELEIRARS SERENE GRUNGE GERAD EE SRST GD GA NN SUNS SD ES SS SD SS SS NS SD SS GES SS GE GES ES GREE EEE GR QE GD SD GS ARE GS ae GEE eee 


| oe 
| 
| 
| 
| 
| 
| 
| 
| 
[ 
r 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
k 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 


206 


of the above referenced publication). This 
value is in hexadecimal and indicates which 
phase of the compiler was in control when 
the error occurred. The value for m may be 
any one of the following: 


m™ Phase 
1 Phase 10 
4. Phase 15 (PHAZ15) 
8 Phase 15 (CORAL) 
10 Phase 20 
20 Phase 25 
40 Phase 30 


EL AM CE ee ee Ee eee Pe : 
| IEKO022I | XGO-IEKCGO | 
aan ; Sie a Sa { | 
| IEKO23I |XTNDED-IEKCTN | | 
pS eee { | 
| IEKO24I |XTNEDED-IEKCTN | | 
 SeceGecyensen ata: | aie aoe canes acai | | 
| IEKO25I |XTNDED-LEKCTN | | 
See ee eee | | 
{ IEKO261I |XTNDED-IEKCTN | | 
[Aeros sea : aaa ena ana | | 
| IEKO27I |XIOPST-IEKDIO | | 
de are as hee See eee Sere a oe oe eae { 
| IEKO28I |XIOPST-IEKDIC | | 
cs eS a a tS le Ss ea es ie Ss dc Sn as | 
| IEKO30I |XDO-IEKCDO 
 ememainrc : acca ean re iaedeaeaes | | 
| IEK031I |XDO-IEKCDC | | 
passes s 1S { | 
| IEKO34I |DSPTCH-IEKCDP | l 
Seatepeorceies | fl ai eae a anaes | | 
| IEKO35I |DSPTCH-IEKCDP | l 
SURGES aa. GENRE Eee ee { | 
| IEKO36I |DSPTCH-IEKCDP | | 
pases Senna agni eas leamea | | 
| IEKO39I |XTNDED-IEKCTN§ | l 
peeersaSs> ; a a aNaiatS | | 
| IEKO4OI |XCLASS-IEKDCL | l 
See ee eed «6 CCHASETO- | 4 
| IEKO47I |XARITH-IEKCAR, | | 
| |XDATYP-IEKCDT | | 
i Se a a a a a | 
| IEKO52I |DSPTCH-IEKCDP | | 
Sea fete ee | 
| IEKO53I |XARITH-IEKCAR, | | 
| | DSPTCH-IEKCDP | 
asians (ae ee ace aceon aU ees | | 
| IEKO56I |XSUBPG-IEKCSR | | 
ee eceeain fe { | 
| IEKO57I |XSUBPG-IEKCSR | l 
pea | gnies dine BOSE RoC | | 
| IEKO58I |XSUBPG-IEKCSR- | l 
capeiiearera aes | eRe = Seeman Aaa | 
| IEKO59I |XSUBPG-IEKCSR | | 
_ Roan A eager ae poe Be ie pen ee CP nie ee ee a a at a tia nga J 


ee eocon kt 
| | DSPTCH-IEKCDP | 
a a 
Tea | 
eetoesn ace eee 
ee a 
eee a 
eae ae 
esos eee 
EERGOR eee | 
a SS { 
{| IEKO73I |XSPECS-IEKCSP | 
oe 
Sra cane ae eeemaia 
Pio ee 
ae eee 
aeese Oe a 
Sec greene ae 
oe aoa 
a a | 
eee a 
 aeROssE TAP er 
eg aa 
 aEecsst (OAH SCIN 
cer ee a 
goa ae 
ener rg een nanerrnrma 
 Geaost Meee 
io ae | 
on aoe 
ne ee ae 
TERiGio esa 
Pe io ee 
PEER (Or WRODSESEERDLO: 
seers nea aa 
Dishes a orn a Fe iL 


[ipa or ee Wo pee a ee a, Moy ay a eo far awe 1 


| IEK113I |XIOPST-IEKDIO 


| | 

~--------+}---------------- { | 
| IEK115I |XIOPST-IEKDIO | l 
-~--------4---------------- { | 
| LEK116I |XDO-IEKCDO | | 
}--------- {---—------~---—- 1 | 
| ILEK1171I |DSPTCH-IEKCDP | | 
~--------}---—------------ { | 
| IEK120I |DSPTCH-IEKCDP | | 
~--------4---------------- { | 
| ITEK121I |XDATYP-IEKCDT | l 
}--------- +---------------- { | 
| IEK122I |XDATYP-IEKCDT | | 
--------- +~----------------4 | 
| IEK123I |XDATYP-IEKCDT | | 
|--------- +---------------- { | 
| IEK124I |XDATYP-IEKCDP | | 
}-------— {------------—-- { 
| IEK125I | XDATYP-IEKCDP | | 
oi ea se ate | 
{| IEK129I |XDATYP-IEKCDT | | 
i a ce a a a as as a | 
{ IEK130I |XDATYP-LIEKCDT | | 
Bey ct nme ena Nc reece De Rien een rar EO | 
| IEK132I |XDATYP-IEKCDT | | 
}--------- +---------------- { | 
| ITEK133I |XDO-IEKCDO | | 
Fe eee Renn PERS Gite th ene ene Seren tree l 
{| IEK134I |XDO-IEKCDO | | 
Sik Sa Da had | | 
| ITEK135I |XDO-IEKCDO | | 
}--------- +---------------- { | 
| IEK136I |XDO-IEKCDO | 
eee ine eens ees eerere me eee eka ee eae | 
| IEK1371I |XDO-IEKCDO | | 
}-——---~-- +--—---------—--- { | 
| IEK1381I |XDO-IEKCDO | | 
}---------}---------------- { | 
| IEK139I |DSPTCH-IEKCDP, | | 
| | XSPECS-IEKCSP, | 
| | XDATYP-LEKCDT | | 
---~----- {----~-----------4 | 
{| IEK140I |DSPTCH-IEKCDP, | | 
| |XIOPST-IEKDIO | l 
See ea ree a ee | 
| ITEK141I |XIOPST-IEKDIO | | 
PRD Reet ee eee! PNW ERI e Oe ee eae TE IS | 
| ITEK143I |DSPTCH-IEKCDP | l 
~-------- +----—----------- | 
| ITEK144I |DSPTCH-IEKCDP | | 
--------- {~---------------4 | 
| IEK145I |DSPTCH-IEKCDP_ | | 
~-------~ {--—--------—-- | 
| IEK1461I |DSPTCH-IEKCDP | | 
--------- +----------------1 | 
| IEK147I |DSPTCH-IEKCDP l | 
~-------- +----------------4 | 
| IEK148I |XSPECS-IEKCSP | | 
}---~--~-- {~-—~-—--~—--—~~ { | 
{| ITEK149I | XSPECS-IEKCSP | | 
--------- +-~-—----------- | 
| IEK150I |{XSPECS-IEKCSP | | 
--------- }----------------} | 
| IEK1511I |XSPECS-IEKCSP | | 
—--—---—-- +—---—-—-—-—-——-—-—-—--—-- PHASE 10 | 
| IEK152I |XSUBPG-IEKCSR | | 
GS aeeeee 2 Sr RL gram Eee en pe ce een Sere ae J 
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es et ee oo ee fe ee ee ee oe eee q 


| IEK153I |XARITH-IEKCAR 
Supa cacneaas eee ea 
| IEK156I |XIOOP-IEKCIO 

| IEK157I |XARITH-IEKCAR 


| IEK159I |XIOPST-IEKDIO 

| IEK160I |XIOOP-IEKCIO, _ 

l | XDO-IEKCDO 

| IEK161I |XIOOP-IEKCIO 
V EERAGiT (xpOLieRenO. 

| IEK165I1 |XIOOP-IEKCIO _ 


+ 

IEK1671 |XARITH-IEKCAR, 
| XSPECS-IEKCSP, 
|XIOPST-IEKDIO, 
| DSPTCH-IEKCDP, 
| XSUBPG-IEKCSR 


> a ee ee ee ee ee 


| IEK168I |XSUBPG-IEKCSR 


| IEK169I |XICOP-IEKCIO 


| IEK170I |XICOP-IEKCIO 


Fe ee 
ak baa 
| | XCLASS-IEKDCL 
Geioen (cpkes nen, 
geonte see 
or ee re 
ecg ea 
een ag pons 
eos ee 
| XSPECS-IEKCSP 
Pee cE ca 
aeecer Wace eee 
 EeRs0Gr (ZARTIRTERCAS 
eo ees 
 SEboOeE (cece 
Ee Ica ce 
Taleo ee 
ee | ieee a cto 
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PHASE 10 


ree ea ee Wns eng ge oe, Chee ee eget ee Mee Soke ey ce eee ee ee 
| IEK225I |DSPTCH-IEKCDP | 
ee a a a ee es ee 4 
| IEK226I |CSORN-IEKCCR | 
iia Sera eee aera eo oo Sa ew ae Se eee ee Se | 
| IEK229I |XARITH-IEKCAR | 
ee Sea ec es eee Sa es ee ee ee 4+-—---—---—---—---- 
| IEK302I |STALL-IEKGST 
Peano ares eet pe ——-—-—-~—-—-—-—-—-—~—-—-—-—-{ 
| IEK304I |STALL-IEKGST 
a SORIA eT era aa ROR { 
| IEK305I |STALL-IEKGST 
-— { 
| IEK306I. |STALL-IEKGST | 
Sa a let ae ea ces haa ea 5 
| IEK307I |CORAL-IEKGCR l 
sea an etcetera —-———-——~———-—--—-—-———f 
| IEK308I |STALL-IEKGST | 
(=== === pasar oes=— ass 
| IEK310I |STALL-IEKGST | 
p=s=—— Ss | ROE RaL aba AMES RECS | 
| IEK312I |STALL-IEKGST | PHASE 10 
a fiers (STATI =I EKGST) 
| IEK314I |STALL-IEKGST | and 
Seceetaes teeeeeseicesesteed “PHAGE. 1S 
| IEK315I |STALL-IEKGST l 
eee Weert ea (CORAL) 
| IEK318I |NDATA-IEKGDA | 
fos = =e == | I Ee aa | 
| IEK319I |NDATA-IEKGDA | 
ae eerie fesse { 
| IEK322I |STALL-IEKGST | 
Pee 1 ER Re eee | 
| IEK323I |STALL-IEKGST l 
Be ny a a ets eae a ee eae { 
| IEK332I |STALL-IEKGST | 
Fos i a ss neal —~-—-—-——-——-——--—-—-—-- 
| IEK334I |STALL-IEKGST | 
loon tas lacs as Gill es owls ae Am aa a geen ee ee av oe oe ae | 
| IEK350I |NDATA-IEKGDA | 
i a al cp a a ce a gs a a a a il a a aes atc ae 4 
| IEK352I |NDATA-IEKGDA | 
sa a ace co le ls em ae es er { 
| IEK353I | IEKGCZ | 
| ITEK356I |STALL-IEKGST l 
a ia a cea ati ee sia ae leet Cocoa a as | 
| IEK500I |STALL-IEKGST | 
poe eee eae ee 82524 55244-=—— 
| IEK501I | UNARY-IEKKUN l 
| (EXPON) 
Ses esae = fae eee eee a4 
| IEK502I |UNARY-IEKKUN | 
| (EXPON) l 
mem as {eee Sea] 
| IEK503I |BLTNFN-IEKJBF | 
ieee | es aie BE IG { 
| IEK505I |PHAZ15-IEKJA | 
f=====-—-= seine aa encestemienieas | 
| IEK506I |ALTRAN-IEKJAL {| 
Seg Clan aiaaa Lae Cuma EE: 
| IEK507I |BLTNFN-IEKJBF | 
——5-2-=—> eee aie ass ate a. 
| IEK508I |BLTNFN-IEKJBF | 
a aia acres  SERERaaiaiae iia aria 
| IEK509I |PHAZ15-IEKJA | 
| EEN eer ee pee RP i ea ees aa en ete es a a are alia 


RE mere eee ee ee ag, eee a ty ee 


| IEK510I JANDOR-IEKJAN 
| IEK5111I |ANDOR-IEKJAN 
l | (LEKKNO) 


ae ae ee ee oe ee ee oe ee ee cae ee er aD eee ane ene aye eee a ee ene eee oe 


| IEK5121 |FINISH-IEKJFI 


| ITEK515I |RELOPS-IEKKRE 

| Tex5161 |FINISH-1EKJFI 
| IEKS201 |ALTRAN-IERIAL | 
| Tex5212 |ALTRAN-IERIAL 
| TEKS221 |ALTRAN-IERJAL 
| TeK5231 {ALTRAN-IERIAL 


———-—-—-~——-—+4-—---—------- jes 


| IEK524I |ALTRAN-IEKJAL 


| ITEK525I |ALTRAN-IEKJAL 


~--------}---------------- 


| IEK526I |RELOPS-IEKRRE 
| IEK527I |ANDOR-IEKJAN 
| IEK528I |BLTNFN-IEKJBF 
| IEK529I |DFUNCT-IEKJDF 
| | (LEKKPR) 

massa s= toae eae eat 
| IEK530I |SUBADD-IEKKSA 
Berea: | Sia ane eRnat { 
| IEK531I |ALTRAN-IEKJAL 
ae | ae cen ae | 
| IEK541I |DFUNCT-IEKJDF 
pear oan : Seah ae { 
| IEK542I |ALTRAN-IEKJAL 
ane | Sia ae | 
| IEK550I |ALTRAN-IEKJAL 
| | DFUNCT-IEKJDF 
| | (IEKKPR) 
| IEK55I |GENER-IEKLGN 
| IEK560I |GENER-IEKLGN 
Riche ee ee es oe ee a hoe sheen Soe ec sien esa etas 


PHASE 15 


(PHAZ 15) 


fees censors queue GEEEENS SENEGE GUEEEED cineeneD GUUGUID SOURS camtGAD <muiMGSSS GuMSUESS GEASWD GUEENGS GOGEDG® ‘ctEhGe OGEILGID SMAUSGD GEMUIEGS GGUS SOULS =EREGSD QmDENtD GEMEEWS ODEN GRGGHS GNEGDS GGG GQUOTGD CODES GAGES GUNGGS GUGAUE GEGMGNGS GERGSS GERD GRR SEES GOES GORGES GEES SUES SESE GES qeneme somes aoe el 


fi Ui ee ee ee Pg ere 1 
| IEK573I |GENER-IEKLGN l | 
{ | TXTLAB-IEKLAB, | | 
| | TXTREG-LEKLRG | l 
|---~--—---}---------~-----~ { | 
| IEK580I |ALTRAN-IEKJAL | PHASE 15 | 
}-—-——------ +—-~—-—-—-—-—~—~-—--~—---- 4 (PHAZ 15) | 
{| IEK581I |SUBMLT-IEKKSM | l 
}--------- +---------------- { | 
| ITEK583I |TXTREG-LEKLRG | | 
}--------- }~--------------- { | 
| IEK584I |MATE-IEKLMA | | 
}~--------- }---------------- { | 
| IEK585I |FINISH-IEKJFI | | 
}~-------- {---——-—--——---—~ {--~—----—-——- { 
| IEK600I |TOPO-IEKPO | l 
}------~-- +---------------- { | 
| IEK610I | TCPO-IEKPO | | 
}-----~-—- }--~-------———- { | 
| IEK631I |GETDIK-IEKPGK | | 
}-—-—-—-—---~--— 4———-~—-—~—~—-——-—--—-——-—— 4 PHASE 20 | 
| IEK650I |TOPO-IEKPO | | 
}~-------- }---------------- { | 
| IEK660I |TCPO-IEKPO | | 
(-S2— Peo eo eee a | | 
| IEK670I |BAKT-IEKPB | | 
PS == 5 kale Rabe ae ec aa { | 
| IEK671I |BIZX-IEKPZ | | 
}--------- {m= | 
{| IEK680I |RELCOR-IEKRRL | | 
}~-------- {----------------+-------------- { 
| IEK710I |STALL-IEKGST l | 
eee ees an ani | 
| IEK720I |STALL-IEKGST | | 
ae | cS a { | 
| IEK7301I |STALL-IEKGST | | 
}-—--—-—----—— +----~—--—--—-—-——---——- 4 PHASE 10 | 
| IEK740I |STALL-IEKGST | (STALL-IEKGST) | 
Eero Toe ee ea ee ee { | 
| IEK750I |STALL-IEKGST | | 
}-------~- +~---------------- { | 
| IEK7601I |STALL-IEKGST | | 
poe = =e Wee er | | 
| LEK770I |STALL-LIEKGST | | 
}--------- {---—-~~----~---- {-------~~~--~- { 
| IEK780I |MAINGN-IEKTA | PHASE 25 | 
}--------- ¢---------------- +-------------- { 
| IEK999I |IEKP30 | | 
}—-——-—-——-—-—~+4--—--—-—-—-—-~-—-—--—-—-{ PHASE 30 | 
| LTEKOO1I | TEKP30 | | 
hace es yee eae at ron See ene ee fea enn Sane ar J 
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APPENDIX I: THE TRACE AND DUMP FACILITIES 


Included in the FORTRAN IV (H) compiler 
are two optional facilities which provide 
output that can be used to analyze compiler 
operation and to diagnose compiler malfunc- 
tion. These two facilities are TRACE and 
DUMP. 


TRACE 


The TRACE facility can be used to trace 
the creation of and the modifications made 
to the information table and intermediate 
text, and to provide various other types of 
diagnostic information. This facility is 
activated by the inclusion of the TRACE 
keyword parameter in the PARM field of the 
EXEC statement used to invoke the compiler. 
The format of this parameter is 


TRACE=value 


where: 
value may be either: (1) any one of 
the basic keyword values appearing in 
Table 53, or (2) any value that is 
formed by adding two or more of these 
basic keyword values. 


The type of diagnostic information to be 
provided by the compiler for a given compi- 
lation or batch of compilations is deter- 
mined according to the value specified for 
the TRACE keyword. Table 53 defines the 
type of diagnostic information produced for 
each of the basic keyword values for the 
TRACE keyword. If one of these values is 
specified, the corresponding information is 
provided by the compiler. For example, if 
the basic keyword value of 4 is specified, 
the compiler generates PHAZ15 diagnostic 
information. 


If the value given to the TRACE keyword 
is the sum of two or more basic keyword 
values, then the compiler will produce the 
type of information that corresponds to 
each basic keyword value that was added to 
form that value. For example, if the value 
12 (the sum of basic keyword values 4 and 
8) is specified, the compiler will generate 
both PHAZ15 diagnostic information and 
CORAL diagnostic information. 
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Table 53. Basic TRACE Keyword Values and 
" Output Produced 


T 
|Basic | | 


|Keyword|Output Produced | 
[Values | | 


| 2 |Printout of the information table| 


| Jas it appears after the execution| 


| {of STALL in Phase 10 | 
}------- }--------------------------------- { 


| 4 |PHAZ15 diagnostic information | 


+ 
| 
H 
|} 1. Intermediate text and infor-] 
| mation table as they arpear | 
| after the execution of Phase| 
| 10. 
{ 2. Information table as it 
| appears after the execution 
| of STALL in Phase 15. 
| 3. Intermediate text and infor- 
| Mation table as they appear 
{ after the execution of 
| PHAZ15 in Phase 15. 
} 4. Information table as it 
| appears after the execution 
| of CORAL in Phase 15. 
| 5. Intermediate text as it 
| appears after the execution 
| of Phase 20. 

128 |Block size information for each | 

Jtext block (Phase 20) | 


ecm OO capcees ERD emacs ES ERE ON OT cme GND cme EES SO ome 


| 256 |Diagnostic information from the | 
| [register assignment routines | 
| | (Phase 20) 


| 512 |Diagnostic information from the | 
| [text optimization routines (Phase| 
| | 20) | 
{| 1024 |Busy-on-exit information for each| 
| {text block (Phase 20) | 


{| 2048 |Additional diagnostic information| 
| [from the register assignment rou-| 
| Jtines (Phase 20) [ 
| 4096 |Printout of intermediate text and| 
| Jinformation table before and | 
| 


|after the execution of Phase 20 | 
aie oe Beat ae ne a a ee ee J 


DUMP 


The dump facility, if activated, will 
cause abnormal termination of compiler pro- 
cessing if a program interrupt occurs dur- 
ing compilation. It will also cause the 
main storage areas occupied by the compil- 
er, as well as any associated data and sys- 
tem control blocks to be recorded on an 
external storage device. The dump facility 
is activated by including in the compile 
step of the job: (1) the word DUMP as a 
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parameter in the PARM field of the EXEC 
statement, and (2) a SYSABEND data defini- 
tion (DD) statement. 


Note: If the DUMP parameter is specified 
kut the SYSABEND DD statement is omitted, 
abnormal termination, accompanied by an 
indicative dump, will occur if a program 
interrupt is encountered. If a program 
interrupt occurs and the DUMP parameter is 
not specified, the current compilation will 
be deleted and the next will be attempted. 
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APPENDIX J: FACILITIES USED BY THE CCMPILER 


The following statements, built-in functions, and facilities are used Ly the compiler 
to compile itself. 7 


(SS 2S SSS See SSRIS a ca aa a a a a a ama a aa aa aaa a a 
|Facility | Purpose 

| STRUCTURE Statement |Provides a means of referring to fields within data structures 

| J|which are located arbitrarily in main storage. The data struc- 
| {tures may consist of sets of fields of mixed type and length. 

| | 

{LAND (a,b) { 

Jbuilt-in function JANDs a and b to oktain a 4-kyte logical result. 

| | 

|LOR (a,b) | 

{built-in function |}ORS a and b to obtain a 4-byte lcgical result. 

| | 

|LXOR (a,b) l 

| built-in function |Exclusive ORS a and b to oktain a 4-byte logical result. 

| | 

|LCOMPL (a) | 

jbuilt-in function |\Takes the compliment of a to obtain a 4-byte logical result. 

| | 

| SHFTL (a,n) | 

Jbuilt-in function {Shifts a left n bit positions to obtain a 4-byte logical result. 
| | 

|SHFTR (a,n) | 

Jbuilt-in function {Shifts a right n bit positions to obtain a 4-byte logical result. 
| | 

{TBIT (c,k) | 

|built-in function {Tests bit k of value c to oktain a 4-byte logical result; on=. 

| | TRUE. , Off=.FALSE. 

| | 

|MOD24 (d) | 

[built-in function {Sets the high-order Lyte of d to zero to obtain a 4-byte integer 


{ jresult. 


| 
|BITCN (v,k) 
|bit-setting statement|Sets bit k of value v on. 


| | 
|BITOFF (v,k) | 
|bit-setting statement|Sets bit k of value v off. 


| 
|BITFLP (v,k) 
|bit-setting statement|Inverts bit k of value v. 


| 
! 
| 
| 
! 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
bk 
| 
i 
| 
| 
| 
| 
| 
i 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
I 
| 
! 
| 
| 
| 
! 
I 
| 
1 
| 
! 
| 
| 
{ 
! 
| 
| 
| 
! 
I 
| 
| 
| 
I 
I 
| 
| 
| 
| 
| 
| 
| 
| 
i 
| 
! 
| 
| 
| 
| 
{ 
| 
| 
| 


|The following error message may appear in connection with a STRUCTURE statement: 


|IEKO60I The expression has a structured variable without a subscript. 
Hp a ch a a i rey ee paernw eee 
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The microfiche directory 


(Table 54) 


APPENDIX K: 


MICRCFICHE DIRECTCRY 


in the program listing, which is contained on microfiche cards at your installation. 


Microfiche cards are filed in alphameric order ky okject module name. 


If you wish to 


is designed to help you find named areas of code 


locate a control section, entry point, or table on microfiche, find the name in column 


one and note the associated object module name. 
fiche, via the object module name; 


IEKOBJT1-1. 


(if it is a routine), 


You can then find the item 
for example, object wodule IEKOBJT1 is on card 


on micro- 


The other columns provide a description of the item, a brief synopsis of its function 


applicable). 


eTable 54. 


: 
| 
| 
| 
| 
| 
| 


S 


ymbolic Name 


| ADMDGN-LEKVAD 


| 
| AFIXPI 


| 
| ALTRAN-IEKJAL 


| ANDOR-LEKJAN 


| BACMOV-LEKQBM 


| BAKT-LEKPB 


BITNFP-LEKVFP 


B 


B 


B 


IZX-LEKPZ 


KDMF-LTEKRBK 


KPAS-ITEKRBP 


BLS-IEKSBS 


B 


LTNFN-TEKJ BF 


BRLGL-IEKVBL 


CGNDTA-IEKWCN 


c 


Cc 
Cc 


IRCLE-IEK¢CL 
LASIF-IEKQCF 


NSTCV-IEKKCN 


its phase, 


Microfiche Directory 


Description 


Entry point 


Arithmetic translation 
routine 


Text generation routine 


| 

| 

| 

| 

| 

+ 

|Code generation routine 
| 

| 

| 

| 

| 

| 

| 

| 

|Text optimization routine 
| 

|Structural determination 
| routine 

| 

| Instruction generation 

| routine 


|MVX routine 


{Printing routine 

|Local register assignment 
| routine 

| Branching optimization 

| routine 


{In-line function routine 


{Code generation routine 


JArray initialization routine 


JUtility subroutine 


{Utility subroutine 


|Constant conversion routine 


|Module 
{Name and 
| CSECT 


ITEKVBL# 
ITEKWCN 
TEKCCL# 


ITEKOCF# 


ns a a a a a a ef a 


its overlay segrent and its flowchart ID 


(if 


yates oy et aS etc se SO Sho ecett @ ON eae ep, ie gs, th 


23 


= 
Nn 


= 
On 


NO 
-) 


NO 
© 


NO 
MN 


NO 
© 


NO 
© 


No 
© 


NO 
>) 


—_ 
mn 


NO NM Nd 
Oo WH wo 


NO 
© 


= 
|Chart 


{Overlay |ID 
Phase |Segment }--------- 


| 
| 
+ 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
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13: 


10 


10 


10 


13 


13 


|* - Cnly 
|Mentioned 
fin Chart 


07 


O7* 
12 


10* 


16 


10* 


O07 * 


pp ea 


{Synopsis 


Table 


Table 


12 


12 


14 


12 


12 


12 


12 


14 


14 
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eTable 54. Microfiche Directory (Continued) 


re ee er a oe ee © eee Ee ee ee as : a ese Pee ee Deer 7 
| | |Ckject | ; |Chart | | 
| | {Module | |Overlay|ID | 
[Symbolic Name |Description . {Name and|Phase|Segment }—------—--- {Synopsis | 
| | |CSECT | | [* - Cnly | | 
| | | Name | | |Mentioned| | 
| | | | | [in Chart | | 
~------------- }------~------------~---------}--------}----- 4 ---=---f--------- f+--------- 
| CORAL-~ITEKGCR |Control routine {IEKGCR# [15 | 6 | 09 |Table 9 | 
| | | | | | | | 
|CPLTST-LEKJCP |Arithmetic triplet routine {TEKICP# {15 | 5 | 07* [|Table 9 | 
| | | | | | | | 
| CSORN-IEKCCR |Collection, conversion, and |IEKCCR# |10 | 2 | == |Table 8 | 
| jentry placement routine | | | | | | 
| | | | | | | | 
|CXIMAG-IEKRCI |Local register assignment {IEKRCI# {20 {| 10 | == |Table 12 | 
| | routine | | | | | | 
| | | | | | | | | 
| DATOUT-IEKTDT |DATA statement processing {IEKTCT# |15 | 6 | 09* |Table 9 | 
| | routine | | | | | | 
| | | | | | | | | 
|DELTEX-IEKQDT |Entry point | TEKOMT# |20 { 9 [ a | | 
| | | | | | | | 
|DFUNCT-IEKJDF |In-line and library function |IEKJDF# [15 | 5 | <= |Table 9 | 
| | routine | | | | | | 
| | | | | | | | 
|DSPTCH-IEKCDP |Dispatcher, key word, and |TEKCCP# |10 | 2 | 03 |Table 8 | 
| Jutility routine | | | | | | 
a | | | | | | | 
{|DUMP15-IEKLER |Error recording routine JIEKLER# |15 | 5 | ae [|Table 9 | 
| | | | | | | | 
| ENDFILE [Entry point |IEKAAOO |FSD | 1 | -- | | 
| | | | | | | | 
| END-ITEKUEN JObject module processing JIEKUEN# [25 | 13 | 21 |Table 14 | 
| | routine | | | | | | 
| | , | | | | 
JENTRY-IEKTEN |Epilogue and prologue JIEKTEN# [25 | 13 | 21* |Table 14 | 
| [generating routine | | | | | | 
| | | | | | | | 
|EPILOG-IEKTEP |Subprogram epilogue generat- |IEKTEP# |25 | 13 [ we |Table 14 | 
| Jing routine | | | | | | 
| | | | | | | | | 
| EOVAR-IEKGEV [Common and equivalence JIEKGEV# |15 | 6 | O9* {|Table 9 | 
| | routine | | | | | 
| | | | | | | | | 
| ESD JEntry point JIEKTLCAD|FSD | 1 | Sali | 
| | | | | | | | 
|FAZ25-IEKP25 |Common data area {IEKP25 |25 | 13 ; =< |Table 14 | 
| | | | | | | | 
|FCLT50-IEKRFL |Text checking routine | IEKRFL# | 20 {| 10 { ae [Tackle 12 | 
| | | | | | | 
|FILTEX-IEKPFT |Entry point | LEKPGK# | 20 | 7 | -- |Table 13 | 
| | | | | | | | 
|FINISH-IEKJFI |Statement processing routine |IEKJFI# |15 | 5 | Q7* |Table 9 | 
| | | | | | | | 
{FIOCS, FIOCS# |Entry points {IEKFIOCS|FSD | 1 | aie | | 
| | | | | | | | 
{FIXPI, FIXPI# |Entry points JIEKAFP |FSD | 1 | = [ | 
| | | | | | | 
|FNCALL-IEKVFN |Calling sequence generating |IEKVFN# |25 {| 13 | |Table 14 | 
| | routine | | | | | | 
| | . | | | | | | 
| FREE-IEKRFR |Local register assignment {IEKRFR# |20 {| 10 | ais [Table 12 | 
| | routine | | | | | | 
As se ee at a ee penal eee a ieee ween y Efeineeaeetierar re pl ener aetna E (Geen ey mente J 

(Continued) 


214 


eTable 54. Microfiche Directory (Continued) 
(ree te ee 5 aaa aa a aaa er 
| | 
| | 
{Symbolic Name |Description 
| | 
| | 
| | 
Se ee Se aCe A fa eee ee ee 


| FUNRDY-IEKJFU |Implicit library function 
| |xreference routine 


| | 
| FWDPAS-IEKRFP |Table building routine 


| 
J|FWDPS1-ITEKRF1 |Local register assignment 
| | routine 


| 
|GENER-IEKLGN |Text output routine 


| | 
| GENERTN-ITEKJGR|Text entry routine 


| 
|GETCD-IEKCGC |Preparatory subroutine 


| 
[Entry point 


[Utility subroutine 


{Utility subroutine 


| 

| GETDIC-IEKPGC 
| 

| GETDIK-IEKPGK 
| 

| GETWD-ILEKCGW 


| 
| GLOBAS-~ITEKRGB |Global register assignment 
| | routine 


| GOTCKK-IEKWKK |Branching routine 


| 
{Entry points 


| 
|IBCOM, IBCOM# 


| 
| TEKAAA 


| Communication takle ITEKAAA 
| LEKAAD ee adcon takle ITEKAAD 
anaes ieoncties initialization LTEKAAOO0 
| | routine 
fey epaaie options, &DDNAMES for|IEKAAO1 
| | compiler 
ee eonetineae deletion routine |IEKAA9 
eens — message takle cues 
anaes aoeden eration routine oe 
feerer — point fern 
ee earatiee routine fe 
freer eae point haces 
ae iecneses dump routine ee 
een ranted routine | TIEKATM 
oon aaeee point aos 
| TEKCLC |enty point aes 


|Module 


|Name and 


Ee ee ee ee ge 


TEKCGW 


ITEKRGB# 


LEKWKK# 


IEKFCOMH|FSD 


| 
|Overlay|ID 


Phase|Segment } 


™  &  — =  —_ 
oO OF 6G OUT 


NO 
© 


ee 
NO NO 
wn © 


| 
| FSD 


| 
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rr 
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te 
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10 


13 


Chart 


* - Cnly 


ee ee H i ial eo ae ee 7 


4Synopsis 


|Mentioned | 


in Chart 


= 
Wn 


15* 


© 
CO 


Table 


Table 


Table 


ae aw aoe 


12 


— 
NO 


12 


14 


i eer nian aac: spemeaey aN: cae SO nemesis ANON sia” NNN ngage SENOS mes <SENNSSO itn SSS: mem Sami “ei | Simm mss ce mr‘ eines cans comm Spin Sma ims ci cms csv“ \ mmm’ incessant Cm emg "nmin eam cp ka eg: Sine nen’, cs son es ma Sti Sees 
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eTable 54. Microfiche Directory (Continued) 


ne Te | ey 


FOS ea a a haa 5 Se eae aan : ces poset esr fo rita a ara 7 

| {|Ceject | | jChart | 

| | {Module | |Overlay|ID | 

{Symbolic Name |Description {Name and! Phase]Segment -}-~----—-—- Synopsis 

| , | | CSECT | | }* - Cnly | 

| | | Name | | |Mentioned | 

| | | | | Jin Chart | 

}---~---------- }----------------------------- +-------- +-----+}------- }--------- }--------- 

J IEKCS1, {Entry points {| IEKCCR# | 10 | 2 | == |Table 8 

|IEKCS2, IEKCS3]| | | | | | 

| | | | | | | 

| LEK FCOMH {Formatted compile-time I/O | IEKFCCMH|FSD | 1 | aed |Table 6 

| | routine | | | | | 

| | | | | | | 

J ITEKFICCS JInterface between compiler, |IEKFICCS|FSD | 1 | == |Table 6 

| | TEKFCOMH and QSAM | | | | | 

| | | | | | 

| TIEKGCR |CORAL controlling routine | TEKCGR# |15 | 6 | 09 |Table 9 

| | | | | | | 

| IEKGCZ |Base and displacement routine|IEKGCZ# |15 | 6 | 09* |Table 9 

| | | | | | | 

| TEKGMP |Storage map routine | ITEKGMP# [25 {| 13 | 20* |Table 14 

| | | | | | | 

| IEKGST |Table entry and text genera- |IEKGST# |10 | 2 | O4 |Table 8 

| jtion utility routine | | | | | 

| | | | | | | 

| LEKIORTN JEntry point JIEKAAOQO |FSD | 1 | me | 

| | | | | | | 

| LEKJA2 |Backward connection takle {IEKJA2 {|15/720| 4 | as | 

| | | | | | | 

| TIEKJA4 |Forward connection table {IEKJA4 |15/720| 4 | == | 

| | | | | | | 

| LEKJEX |Entry point J ITEKKUN# |15 | 5 | O7* | 

| | | | | | | 

| LEKJMO {Entry point JIEKJCP# |15 | 5 | O7* | 

| | | | | | | 

| LEKKNG {Entry point | IEKKOP# |15 | 5 | a | 

| | | | | | | 

| LEKKNO [Entry point | LEKJAN# [15 | 5 | O7+* | 

| | | | | | | | 

| LEKKOS {Coordinate assignment routine|IEKKOS [10 | 2 | O4* |Table 8 

| | | | | | | 

| TIEKKPR {Entry point J IEKIJDF# [15 | 5 | 07* | 

| | | | | | | 

| LEKKSW [Entry point | IEKKUN# [15 | 5 | -- | 

| | | | | | | 

| LEKPFT {Entry point | LEKPGK# | 20 | 7 | waco | 

| | | | | | | 

| LEKPGC [Entry point | TEKPGK# | 20 | 7 | == | 

| | | | [ | | 

| LEKP30 {Controlling routine [IEKP30 |30 | 12 | 22 {Tackle 15 

| | | | | | 

| ITEKP31 |Error message writing routine|IEKP31# {30 | 12 { 22* |Table 15 

| | | [| =| | | 

| IEKQAB |Entry point | ITEKQAA# | 20 | 8 | == | 

| | | | | | | 

| TEKODT | {Entry point | IEKOMT# | 20 | 9 | => | 

| | | | | | 

| LEKQOF {Entry point | TEKOCL# | 20 | 9 | = | 

| | | | | | | 

| LEKOMF {Entry point | ITEKQCF# |20 | 9 | =i | 

| | | | | | | 

| TEKOPX [Entry point | ITEKQCF# |20 | 9 | => | 

| | | | | | 

| TEKQYS JEntry point JIEKQOXS# | 20 | 9 | ad | 
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eTable 54. Microfiche Directory (Continued) 

pee ee Mena ee ee ee eR ee oo yaaa arias 2 ea saa aad Meee on 1 
| | |Ckeject | | {Chart | | 
| | [Module | |Overlay|ID | | 
{Symbolic Name |Description |Name and|Phase|Segment }—-—--—-—---- {Synopsis | 
| | [CSECT | | [* - Cnly | | 
| | | Name | | |Mentioned | | 
| | | | | [in Chart | | 
|-------------- +---------------------------- 4-------- 4-----}------- 4--------- 4--------- { 
| ILEKQOZS [Entry point JIEKOXS# | 20 | 9 | a | | 
| | | | | | 

| TEKRAL JEntry point | IEKRFL# |20 {| 10 | oi | | 
| | | | | | | | 
| LEKRTF [Entry point | IEKRFL# | 20 {| 10 {| -- | l 
| | | | | | | | 
| LEKTDC {Listing routine |IEKTCC# | FSD | 1 | ae |Table 6 | 
| | | | | | | | 
| LEK TDF {Define file statement routine|IEKTDF# |15 | 6 | 09* |Table 9 | 
| | | | | | | | 
| TEKTDT |Data statement routine {IEKTDT# |15 | 6 | O9* |Table 9 | 
| | | | | | | | 
| LEKTLOAD |ESD, TXT, RLD, and loader END|IEKTLCAD|FSD | 1 | -- |Table 6 | 
| [record building routine | | | | | | 
| | | | | | | | 
| LEKTXT {Entry point {IEKTLOAD|FSD | 1 | oe | | 
| | | | | | | | 
| LEKUND JEntry point |IEKTLOAD|FSD | 1 | ae | | 
| | | | | | | | 
| LEKURL [Entry point {IEKTLCAD|FSD | 1 | -- | 
| | | | | | | | 
| TIEKUSD [Entry point JIEKTLOAD|FSD | 1 | aa | | 
| | | | | | 
| LEKXRF |XREF routine |IEKXRF |-- | 3 | = | | 
| | | | | | | | 
| IEKXRS {Utility routine for XREF JIEKXRS |10 | 2 | se |Table 8 | 
| | | | | | | | 
| TEND [Entry point |IEKTLOAD|FSD | 1 | a= | | 
| | | | | | | | 
| INVERT-IEKPIV |Entry point | TEKPGK# |20 | 7 | -- | | 
| | | | | | | | 
{IOSUB-IEKTIS |Calling sequence generating |IEKTIS# |25 | 13 | 20* }Table 14 | 
= or er oe ee 
| TOSUB2-IEKTIO |Calling sequence generating |IEKTIC# [25 | 13 | a= |Table 14 | 
| | routine | | | | | 
| Jo | | | | | | | 
| KORAN-LTEKGKO [Utility subroutine JIEKQKO |20 | 9 | 13* |Table 13 | 
| | | | | | | | 
|LABEL-IEKTLB |Statement number routine | LEKTLB# |25 | 13 | 20* |Table 14 | 
| | | | | | | | 
{LABTLU-IEKCLT |Statement number utility | IEKCLT# | 12 { 2 | = |Table 8 | 
| | routine | | | | | | 
| —— | | | | | | 
| LISTER-IEKTLS |Listing routine JIEKTLS# |25 { 13 | Pans |Table 14 | 
| | | | | | | 
| LOC-IEKRL1 |Register assignment data JIEKRL1 [20 | 10 | a= |Table 12 | 
| | | | | | | | 
| LOOKER-IEKLOK |Subprogram table look up |IEKLCK |15 | 5 | 0O7* |Table 9 | 
| | routine | | | | | | 
| 3 | | | | | | 
| LORAN-IEKQLO [Entry point | TIEKQKO# |20 | 9 | O9* {Table 13 | 
| | | | | | | 
|LPSEL-IEKPLS {Control routine {|IEKPLS# |20 | 7 | 10* |Table 12 | 
| | | | | | | 
|MAINGN-IEKTA |Control routine |IEKTA# |25 {| 13 | 20 {Table 14 | 
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Description 


| MAINGN2-ITEKVM2|Control routine 


eer 
OpeEE Tao 
eu teeaeone 
Wi Seupaeninosa 
es ues 
| OP 1CHK-ILEKKOP 
epee ant 
 SNERERRRRIEE 
oe 

| PAREN-IEKKPA 
ape eEReOBs 
PS EepORSEEKORE 
oaace 

ee 

anges 
‘piosmaes 

| op Seauerape 
eRe nOgeEEeEDR 
ene 


| PUTX-IEKCPX 


| 
| REDUCE-IEKQSR 


| 
| REGAS-IEKRRG 


| 

| 

| RELCOR-IEKRRL 
| 
| RELOPS~IEKKRE 
| 
| 
| 


RETURN-IEKTRN 
R 
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| 
{[MVS, MVF, MVX routine 


| 
{Entry point 


| 
JUtility subroutine 


[Error message writing routine|IEKP31# 


{Data text routine 


|Operand one routine 


|Namelist statement routine 


{TXT record packing routine 


| 
{Entry point 


|Parenthesis routine 


| 
{Entry point 


{Constant routine 


| 
{Entry point 


| 
{Entry point 


| 
{Entry point 


|Common data area 


|Code generation routine 


|Prologue generating routine 


| 
JEntry point 


| 
{Entry placement utility 


| routine 


}Strength reduction routine 


|Full register assignment 
| routine 


| 
{Entry point 


|Relational operator routine 


| 
|RETURN statement routine 


| 
JEntry point 
4 


Table 


able 


oe: | 


able 


Table 


: aaa 5 acl a aaa ee 
|Ceject | | [Chart 
{Module | jOverlay|ID 
[Name and|Phasel Segment }--—--—--—-—-—- 
{| CSECT | | [* - Cnly 
| Name | | |Mentioned | 
| | | fin Chart 
+-------- +-----4------- + 
JIEKVM2# [25 {| 13 | ae 
| | | | 
{IEKLMA# |15 | 5 | -- 
| | | | 
JIEKQOCF# |20 | 9 | aco 
| | | | 
J IEKOMT# | 20 | 9 == 
| | | | 
{30 {| 12 | 22* 
| | | | 
J IEKGCA# |15 | 6 | 09* 
| | | | 
JIEKKCP# [15 | 5 | cis 
| | | | 
| ITEKTINL# |15 | 6 | 09* 
| | | | 
JIEKTPK# [25 | 13 | <o 
| | | | 
JIEKAAO1 |FSD_ | 1 | = 
| | | | 
J TEKKPA# |15 | 5 | Q7* 
| | | | 
JIEKOCF# | 20 | 9 | ie 
| | | | 
| IEKCPF# |20 | 9 | ce 
| | | 
{IEKATM |FSD_ | 1 | oo 
| | | 
{IEKATM |FSD | 1 | -- 
| | | | 
|IEKAIM |FSD | 1 | -- 
| | | 
{| IEKCAA |10 | 2 | == 
| | | 
JIEKVPL# |25 | 13 | == 
| | | | 
{IEKTPR# |25 | 13 | 21% 
| | 
|IEKAPT |FSD | 1 | -- 
| | | | 
| TEKCPX# |10 | 2 | ast 
| | | | 
| | | | 
| TEKCSR# |20 | 9 | 13 
| | | | 
{| TEKRRG# | 20 | 10 | 14 
| | | | 
| | | | 7 
| TEKRFL# | 20 {| 10 | 19* 
| | | | 
| IEKKRE# |15 | 5 | 07* 
| | | | 
JIEKTRN# | 25 {| 13 | 22* 
| | | | 
{IEKTLOAD|FSD | 1 | -- 
faerie y eres 5 Paeaemeperee a ae eee eee ome 
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@eTable 54. Microfiche Directory (Continued) 


earn ag a Ee ee a ee eT ee ee ee ee 

| | {|Coject | | {Chart | 

| | {Module | | Overlay|ID | 

[Symbolic Name |Description {Name and|Phase|Segment }—-----—--—-— {Synopsis 

| | | CSECT | | |* - Only | 

| |Name | | {Mentioned | 

| | | | | Jin Chart | 

}-------------- }~-------~-----—-------------- }-------- $-----}------- +--------- $---—~-~-- 

| SEARCH-IEKRS |Register loading routine |IEKRS# {20 {| 10 | 17* |Table 12 
| | | | | | 

|SPLRA-IEKRSL |BasSic register assignment J IEKRSL# | 20 | 11 | == |Table 12 

| | routine | | | | | 

| | | | | | 

| SRPRIZ-LEKQAA |Structured source program J TEKQAA# {20 | 8 | eed |Table 12 

| {listing routine | { | | | 

| | | | | | | | 

|SSTAT-IEKRSS |Status setting routine |ITEKRSS# | 20 {| 11 | 10* |Table 12 

| | | | | | | 

|STALL-IEKGST |Table entry and text genera- |IEKGST# |10 | 2 | 04 |Table 8 

| |tion utility routine | | | | | 

| | | | | | | 

| STOPPER-IEKTSR|STOP and PAUSE statement |IEKTSR# |25 {| 13 | = |Table 14 

| | routine | | | | | 

| | | | | | 

| STTEST-IEKKST |Replacement. statement routine|IEKKST# |15 | 5 | O7* |Table 9 

| | | | | 

|STXTR-IEKRSX |Control routine J IEKRSX# |20 {| 10 { 18 |Table 12 

| | | | | | 

| SUBADD-IEKKSA |Subscript computation routine|IEKKSA# |15 | 5 | O7* |Table 9 

| | | | | | | 

| SUBGEN-IEKVSU |Code generation routine JIEKVSU# |25 | 13 | 20* |Table 14 

| | | | | | 

| SUBMULT-IEKKSM|Subscript computation routine|IEKKSM# |15 | 5 | O7* |Table 9 

| | | | | | | 

| SUBSUM-ITEKQSM |Operand and operand value JIEKQSM# | 20 | 9 | a= {|Table 12 

|replacement routine | | | | | 

| | | | | | | 

|TARGET-IEKPT |Loop and back target routine |IEKPT# |20 | 7 | 10* |Table 12 

| | | | | | | 

| TENTXT-IEKVTN |Statement processing and JIEKVIN# [25 | 13 | 20* |Table 14 

| {label map routine | | | | | | 

| | | | | | | | 

| TIMERC [Entry point {IEKATM |FSD_ | 1 | = | 

| | | | | | | 

|TNSFM-LTEKRTF |Entry point | LEKRFL# | 20 | 10 | me { 

| | | | | | 

| TOPO-TEKPO |Back dominator routine JIEKPO# [20 | 8 | 10* |Table 12 

| | | | | | | 

| TOU [Entry point |IEKATM  |FSD_ | 1 | == | 

| | | | | | | 

{TSP {Entry point J}IEKATM |FSD | 1 | == | 

| | | | | | | 

[TST [Entry point JIEKATM |FSD | 1 | == | 

| | | | | | 

{TSTSET-IEKVTS |Code generation routine JIEKVTS# | 25 | 13 | == |Table 14 

| | | | | | | 

{TXT [Entry point [| IEKTLOAD|FSD | 1 | as | 

| | | | | | 

|TXTLAB-IEKLAB |Statement number processing |IEKLAB# |15 | 5 | 08* iTable 9 

| | routine | | [ | [ 

| | | | | | 

|TXTREG-IEKLRG |Standard text processing | IEKLRG# |15 | 5 | 08* |Table 9 

| | routine | | | | | 
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eTable 54. Microfiche Directory (Continued) 


fe ae Mes ey i nee i a mia aca ; aaa 5 aera 2 ee 1 
| | |Ckject | | jChart | | 
| | {Module | | Overlay |ID | | 
{Symbolic Name |Description |Name and|Phase|Segment }---—-—--—--—- {Synopsis | 
| | [CSECT | | [* - Cnly | 
| | | Name | | |Mentioned | | 
| | | | | [in Chart | | 
~------------- f-----------------------------f-------- 5 ---f --- =f === f= 
| TYPLOC-IEKQOTL |Strength reduction routine | IEKOTL# | 20 | 9 | 13* |Table 12 | 
| | | | | | | 
JUNARY-IEKKUN |Arithmetic triplet and | ITEKKUN# | 15 | 5 | 07* |Table 9 | 
| jexponentiation operator | | | | [ | 
| | routine | | | | | | 
| | | | | | | | 
| UNRGEN-ITEKVUN |Code generation routine {IEKVUN |25 | 13 | == |Table 14 | 
| | | | | | | | 
| WIRTEX-IEKQWT |Diagnostic trace printing JIEKQWT# | 20 | 3 | == |Table 12 | 
| | routine | | | | | | 
| ho. | | | | | | | 
|XARITH-IEKCAR |Arithmetic routine J TLEKCAR# | 10 | 2 | oss |Table 8 | 
| | | | | | | | 
|XCLASS-IEKDCL |Text generation utility JIEKDCL# |10 | 2 03* {Table 8 | 
— ecm to |g te mee | 
|XDATYP-IEKCDT |DATA and TYPE keyword routine|IEKCCT# |10 | 2 | <s |Table 8 | 
| | | | | | | | 
| XDO-ITEKCDO {DO keyword routine JIEKCCC# | 10 | 2 | ial |Table 8 | 
| | | | | | | | 
| XGO-IEKCGO {GO TO keyword routine | ITEKCGO# | 10 | 2 | == |Table 8 | 
| | | | | | | | 
|XIOOP-IEKCIO {I/O statement routine |IEKCIO# | 10 | 2 | ae {|Table 8 | 
| | | | | | | | 
{XPELIM-IEKQXM |Common expression elimination|IEKQXM# | 20 | 9 | 11 {|Table 12 | 
| | routine | | | | | | 
| | | | | | | | | 
|XSCAN-IEK@XS |Local block scan routine [| TEKOXS# | 20 | 9 | ae {Table 12 | 
| | | | | | | | 
|XSPECS-IEKCSP |COMMON, DIMENSION, and EQUI- |IEKCSP# | 10 | 2 | == |Table 8 | 
| {VALENCE table entry routine | | | | | | 
| | | | | | | 
| XSUBPG-IEKCSR |CALL, SUBROUTINE, ENTRY, and |IEKCSR# | 10 | 2 | -- |Table 8 | 
| | FUNCTION table entry routine | | | | | | 
| | | | | | | | 
|XTNDED-IEKCTN |DEFINE FILE, NAMELIST, and |IEKCIN# |10_ | 2 | -- |Table 8 | 
| | STRUCTURE table entry routine| | | | | | 
| | | | | | | 
{|XITOPST-IEKDIO |ASSIGN, RETURN, FORMAT, JIEKDIO# |10 | 2 | == |Table 8 | 
| |PAUSE, BACKSPACE, REWIND, END] | | | | | 
| | FILE, STOP, and END table | | | | | | 
| Jentry routine | | | | | | 
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ABS 31 
Absolute constant 59 
Activity table, global register 
asSignment 49 
Adcon table 37,67,112 
Space reservation 36,41 
Starting address of 50 
in XREF processing 25 
Adcon variable 40 
Addition, skeleton instructions’ 160 
Additive text, elimination of 62 
ADDR 31 
Address 
computation for array elements 201 
constant 11,13,38-39 
reservation of 64-65 
field of TXT record 63 
relative 306 
assignment of 13 
Adjective codes 133-134 
ADMDGN-IEKVAD 105,213 
AFIXPI 74,213 
AIMAG 31 
ALTRAN-IEKJAL 27-29,32,86,213 
Anchor point 32 
AND 31,32 
ANDOR-IEKJAN 32,86,213 
Argument save table 32 
Arithmetic 
expressions 
elimination of 58-60 
reordering 28-29 
special processing 29-32 
interruptions 176 
operations, basic register assignment 
4W4U-45 
statements, processing 21 
Subroutines 19-21 
translation 26,27,36 
Array 18 
elements, address computation 201 
relative address for 38 
Arrays 155 
bit strip 66 
as parameters 201 
ASSIGN statement 20,27 
Assigned GO TO operator 153 


Back dominators 51,204 
determination of 52-53 
in common expression elimination 59 
Back targets 51,52,204 
determination of 53-54 
pointer to 57 
BACKSPACE statement 66,167 
Backward connections 27,35-36 
field 35 
table 35,51 
Backward movement 60-61 
example of 163 
BACMOV-LEKQBM 60-61,100,213 


INDEX 


RAKT-IEKPB 51,53,54,100,213 
Balanced tree notation 114 
Rase value of equivalence group 39 
Base variables 40 
Basic register assignment 42,205 
Binary 
Oferators 147 
Shift operation 150 
Bit strip arrays 66 
BITFLP 212 
BITNFP-IEKVFP 105,213 
BITCFF 212 
BITCN 212 
BIZX-IEKPZ 55,100,213 
BKDMP-IEKRBK 100,213 
BKPAS-IEKRBP 47,48,100,213 
Blanks, in source Statements 19 
BLKENC field 27,144 
Block determination for branching 
Optimization 50-51 
BLS-IFKSBS 50,63,100,213 
BLTNFN-IEKJBF 30,31,86,213 - 
Roundary alignment option 136 
Branch 
candidate 068 
constant 61 
instruction optimization 50 
Orerator (B) 147 
operator (other) 150 
Optimization 42 
OPT=1 49-51 
CPT=2 63 
processing, phase 25 67-68 
takle 22,125,126 
entry 65 
text entry 59 
true or false skeleton instructions 157 
variable 61 
Branch on index high, low, or equal 149 
Branching optimization 42 
block determination for 50-51 
OPT=1 49-51 
OPT=2 63 
BRLGL-IEKVBL 105,213 
Buffering 180 
IHCDIOSH 185 
Built-in functions 212 
Busy-on-entry 55 
table 55-56 
Rusy-on-exit 
criteria 56 
data 204 
full register assignment OPT=2 62-63 
table 55-56 
vector field 144 
BVA table 129 
Byte A usage field 
for statement numbers 120 
for variables 117 
Byte B usage table field 
for statement numbers 121 
for variakles 117 
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Call 20,21,27 
in global register assignment 49 
in local register assignment 48 
phase 25 processing of 66 

Call arguments 152 

Call-by-name 
parameters 69 
variables 41 

Calling sequence 66 

Cataloged procedures 11 


CGNDTA-IEKWCN 105,213 
CIRCLE-LIEKQOCL 102,213 
CLASIF-IEKQCF 102,213 
Classification ; 

code 19 

tables 109-112 
CMAJOR 35,51,53,57,203 
CNSTCV-IEKKCN 86,213 


Code generation, phase 25 66-68 
Collection subroutines 22 
Common 12,18,20,69 
areas table 88 
block 
name 20 
size 24 
entries 22,24 
expression elimination 
example of 162 
table 123-125 
Communication table 14,15,74 
contents of 14,109-110 
Commutative expressions 30 


58,60 


Compiler 
initialization 14-15 
I/O flow 11-12 


generated branch 33 
Organization of 11 
purpose of 11 
Structure of 13 
termination 17-18 
Complex 
expressions 28 
variables 23 
Computed GO TO 
Operators 149 
Skeleton instructions 159 
CONJG 31 
Constant 
complex 23 
dictionary entry 119-120 
relative addresses for 38 
Constant/variable usage information 
phase 15 26 
Constructing text information 
Control flow, phase 20 42-43 
Conversion 
code 171 
routines 177 
Subroutines 22 
Coordinates 23 
assignment of 22,23 
CORAL 15,36-41,204 , 
CORAL-IEKGCR 36,38,39,41,86,214 
CPLTST-IEKJCP 86,214 
Cross reference 12 
CSORN-IEKCCR 78,214 
in XREF 25 
CTLBLK format 181 


32,33 


63-64 
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Current tase address, in register 
asSignrent 45 

CXIMAG-IEKRCI 100,214 

C1520-IEKJA2 35 


Data definition statements 11 
CATA statement 13,18, 132 
Data text 
crhase 10 18 
| format 136 
Phase 15 format 140 
rechaining 36,40 


translaticn 36,37 
DATOUT-IEKTDT 36,37,86,214 
DCB 14 
DCRDCDNM field 14 
DCMPLX 31 
DCONJG 31 
DEBUG# 188 
DECB skeleton section of IHCFICSH 178,179 
DECK option 12,13,63 
DEFINE FILE 

Staterent 18,40,132 

text 123 


chase 10 18 
format 138 
Definition vector field 144 
Deletion 
of compilation 17 
kefore phase 20 13 
DELTEX-IEKODT 102,214 
Derth nurkers 51,52 
determination of 53-54 
DFILE-IEKTDF 36,40,86 
DFUNCT-IEKJDF 30,31,86,214 


Diagnostic message 206-209 
takles 
error table 74,131 


message pointer 131 
Diagnostic traceback 176 
DIMENSION statement 20 
Direct-linkage calling sequence 66 
Directory array 66 
Dispatcher subroutine 19 
Displacenent for adcon 37 
Division skeleton instruction 160 
DC 22 | 

implied 21 

in strength reduction 61 
Doukle buffering 180 
DSPTCH-IEKCDP 19,20,21,78,214 
Dummy argunments 21 _ 
DUMP 177 
Dump 211 


DUMP15-IEKLER 86,214 


EDIT option 12,13,18,19,56 
EMIN takle 47 
Eminence table 47 
End mark operator 
Fnd of DO IF 32 
End of file 17 
END statement 11,17,19 

phase 25 processing if 68 
ENDFILE statement 17,167,214 
END-IEKUEN 86,105,214 


19,20 


External symbol dictionary 


“FILTEX-IEKPFT 


-FIOCS, FLOCS# 


Entry block 27,33,52 
Entry coding 
. Main program 16,65 
Subprogram main 16-17 
Subprogram secondary 17 
Entry placement subroutine 21 
ENTRY Statement 17,27 
ENTRY-IEKTEN 105,214 | 
EPILOG-IEKTEP 68-69,105,214 
Epilogue 16,17,64,69 
Equivalence 22 
group 20 
head 24 
variable 20 
EQUIVALENCE statement 12,18,20,24,38,69 
EQVAR-IEKGEV 36,39,40, 86,214 


Error 
code table 70 
levels 17,70 


message processing 176 
object-time 167 
phase 10 response to 12 
phase 15 response to 13 
source statement, object-time 
table 12,69-70,74 

ESD entry point 214 

ESD record 41 

Execute statement 

Exit block 53 
as forward target 57 


188 


11,14 


EXIT library subprogram 177 
EXT operator 152 
EXTERNAL statement 20,31 


11,13,41, 63 


FAZ25-IEKP25 
FCLT50-IEKRFL 
Field count 


105,214 
100,214 
22,171 
102,214 
167 
86,214 
214 
Fixed point skeleton instructions 
FIXPI,FIXPI# 214 
FLOAT 31 
FNCALL-IEKVFN 66,105,214 
FOLLOW-IEKOF 100,102 
Forcing strength 28-29 
definition of 28 
table 29 
Format 
codes with READ/WRITE 16 
of source statement after phase 10 19 
text 132 
phase 10 18 
format 138 
translation 22-23 
FORMAT statement 16,18,22,23, 
FORMAT-IEKTFM 22,214 | 


FIND statement 
FINISH-IEKJFI 


159 


132 


FORTRAN system director 11,14-18 
Forward , 
connection 27,33-34 
field 35 
table . 35,51 
target 57 
FREE-IEKRFR 100,214 
FSD 203 
(see NPTR) 


pointer table 


Full register assignment 42,205 

control 47 

global 47,49 

local 47-48 

OPT=1 46-49 

OPT=2 62-63 

table building 47-48 

text updating 47,49 
Full-word integer division skeleton 

instructions 160 

Function arguments 152 
FUNRDY-IEKJFU 30,215 


FUNTB1 127 
FUNTB2 127 
FUNTB3 127 
FUNTB4 127 


FWDPAS-IEKRFP 
FWDPAS1-IEKRF1 


47,100,215 
100,215 


GENER-IEKLIGN 28,86,215 


GENRTN-IEKJGR 86,215 
GETCLD-IEKCGC 18,78,215 
GETDIC-IEKPGC 102,215 
GETDIK-IEKPGK 102,215 
GETWD-IEKCGW 78,215 
GLCBAS-IEKRGB 47,49,62,100,215 


Global assignment 46-49 
full register assignment CPFT=2 
tables 130 
GC TO statement 
computed 18,64,125 
in gathering forward connection 
information 33 
GOTOKK-IEKWKK 105,215 
GRAVERR 70 


62-63 


H format code 22 

Half-word integer division skeleton 
instructions 158 

Head of equivalence group 39 

Hollerith character strings 38 


Housekeeping section of IHCFICSH 178 
IBCOM,IBCOM# 215 
IBCOMRTN 17,215 
IBFERR 176 

IBFINI 65,68,176 
ID oftion 109 
IEKAAA 14,74,215 
IEKAAD 74,215 
IEKAAOO 74,215 
ITEKAAO1 74,215 
IEKAAQ9 17,74,215 
IEKAER 74,215 
IEKAFP 14,215 
IEKAGC 15,74,215 
IEKAPT 74,215 
IEKAREAD 215 
IEKATB 74,215 
IEKATM 74,215 
IEKCAA 15 

IEKCDP 19 

IEKCIN 215 

IEKCLC 78,215 
IEKCS1, CS2, CS3 78,216 
IEKFCCMH 16,74,216 
IEKFIOCS 16,74,216 
IEGCR 216 


Index 223 


IEKGCZ 36,40,41, 86,216 
IEKCMP 69,106,216 
IEKGST 216 
IEKIORTN 216 
IEKJA2 216 
IEKJA4 216 
IEKJEX 216 
IEKJMO 216 
IEKKNG 216 
IEKKNO 216 
IEKKOS 23,24,78,216 
IEKKPR 216 
IEKKSW 216 
IEKLFT 30,126-127 
IEKPFT 216 
IEKPGC 216 
IEKP30 216 
IEKP31 108,216 
IEKQAB 216 
IFKODT 216 
IEKQF 216 
IEKOMF 216 
IEKOPX 216 
IEKQYS 216 
IEKQZS 217 
IEKRAL 217 
IEKRTF 217 
IEKTDC 74,217 
IEKTDF 217 
IEKTDT 217 
IEKTLOAD 16,17,74,217 
generating literal data text 22 
main program entry coding 65 
in relative address assignment 38 
Space reservation 41 
IEKTXT 217 
IEKUND 217 
IEKURL 217 
IEKUSD 217 
IEKXRF 217 
IEKXRS 25,78,217 
IEND 68,217 
INVERT-IEKPIV 100,102,217 
IF statement 20,27 
IHCADST 167,176 
IHCDBUG 167,188-190 
IHCDIOSH 167,183 
buffering 185 
communication with the control program 
185 
file definition section 185 
file initialization section 186 
operation 185-188 
read section 187 
routine directory 199 
termination section 188 
write section 187-188 
IHCFCOMH 40,65,167 
format code processing 170 
subroutine directory 194 
IHCFCVTH 167,170,194 
IHCFIOSH 167,177 
closing section 182 
communication with the control program 
180 
device manipulation section 182 
initialization section 180-181 
read section 181-182 


224 


routine directory 199 
write section 182 
IHCIBERH 176,188 
ITHCTRCH 167,190 
IHCUATBL 179,180 
ILEAD 35,121-122 
Implied DC 21 
INCNAMEL 167 
Index register 67 
Inert text entry 59,61 
Information table 12,15 
chains 112-113 
construction of 113 
operation of 
branch table 113,116 
cormon 113,115 
dictionary 113,114 
equivalence 116 
literal constant 113,116 
statement number 26,27,113,115 
components’ 18 
branch table 18, 125-126 
commen table 18,24,123-125 
dictionary 18,116-120 
literal table 18,125 
entries constructed by phase 10 20 
Initial value assignment 36,41 
Initialization 
of compiler 14-15 
of data fields 14-15 
of IHCFIOSH 180-181 
instructions, generation of 16-17 
In-line routine 30,31,151 
in branching optimization 50 
functions 148 
Skeleton instructions 155-156,159,161 
Integer constants, elimination of 61 
Intermediate text 12,18,132-155 
chains 132-133 
phase 20 modifications 145 
Intermediate text entry 
format of 133 
modifications by phases 15 and 20 
140-155 
Internal statement number 12 
in phase 30 70 
Interruption 
mask 65 
processing 176 
Interruptions 
arithmetic 176 
Specification 176 
IOSUB-IEKTIS 65-66,105,217 
ICBSUB2-IEKTIO 105,217 
I/O data list 27 
I/C device rmanipulation routines 175-176 


I7C list items 21,169 


conversion routines 177 
I/O recovery procedure, execution-time 196 
I/O requests 
processing of 16 
request format 16 
I/O staterent 21 
phase 25 processing of 65-66 
ISN 12,19 


JLEAD 35,121-122 
Jok statement 11 


Keyword 
pointer table 111 
source Statement 20 
Subroutines 19,20 
table entry 20 
table entry and text 20 
table 111-112 
KORAN-IEKQKO 102,127,217 


LABEL-IELTLB 65,105,217 
LABTLU-IEKCLT 78,217 
in XREF 25 
LAND 31,212 
LBIT operator 154 
LCOMPL 212 
LIBF operator 152 
Library function 31 
Subprograms 167 
Linkage editor 11,13 
LISTER-IEKTLS 105,217 
LIST option 12,13 
Listing, structured source program 56 
Literal 
data text 22 
table 125 
LMVF 57-58 
LMVS 57-58 
LMVX 57-58 
Load address 
operator 150 
skeleton instructions 158 
Load byte skeleton instructions 158 
Load candidate 068 
LOAD option 12,13,17,63 
Loader END reccrd 63,69 
Local 
asSignment tables 129 
register assignment 46-48 
symbol 41 
Location counter 38,63 
in.relative address assignment 37 
LOC-IEKRL1 100,217 
Logical 
branch operations 147,154 
expressions 32 
IF statements 19,32 
in strength reduction 61 
skeleton instructions 160 
LCOKER-IEKLOK 217 
Loop 204 
composit matrixes 57 
identification 51 
number 54 
field 53 
parameter 56-57 
selection 56-58 
Loops 
depth numbers of 54 
identifying and reordering 54 
module 51 
LOR 31,121 
LORAN-IEKQLO 102,217 
LPSEL-IEKPLS 42,47,49,56,100,217 
LXOR 31,212 


Main program entry coding 65 
Main storage, requests for 
phase 10 15 


phase 15 15-16 
phase 20 16 
MAINGN-IEFKTA 64-65,68-69,105,217 
MAINGN2-IEKVM2 218 
MAP option 13,63 
Mar, storage 13,69 
MATE-IEKIMA 32,33,87,218 
MBM 157-128 
MBR 127-128 
MCCORD vector 24,40,47,129 
Message 
number 70,131,206-209 
erocessing 69-70 
takles 74-131 
Messages, error 
during phase 25 13 
phase 30 processing of 69-70 
MGM 127-128 
Microfiche directory 213-220 
Mid-fpoint of dictionary chain 114 
Mode 20 
Mode field in status mode word 145 
MODFIX-IEKOMF 102,218 
MOD24 212 
MOVTEX-IEKQOMT 102,218 
MSGM 127-128 
MSGWRT-IEKP31 70,108,218 
MSM 127-128 
Multiplicative text, elimination of 61 
MVD table 24,40,47 
in busy-on-exit 55 


entry 32 
MVF 24,32,33,144 
field 55 


MVS 24,32,33,144 
MVU 127-128 
MVV 127-128 
MVW 127-128 
MVX 24,32,33,144 
field in bkusy-on-exit 55 
MXM 127-128 


NADCCN table 37,112 
use in parameter list optimization 31 
Namelist 
dictionaries 22,130-131 
entry 40 
text 132 
phase 10 18 
forrat 137 
NAMELIST statement 18,40,132 
NARGSV 32 
NCARD/NCDIN 19 
NDATA-IEKGDA 36,37,87,218 
Negative address constants 39 
NLIST-IEKTNL 36,40,87,218 
Normal text 15,132 
phase 10 18 
format 135 
NCT 32 
oferations, skeleton instructions 157 
Not kusy on entry, definition of 32 
NPTR 22,25,74,109-110 
Null operand 21 


Ckject module 


definition of 11 
elements of 63-64 


Index 225 


generation of entry code 22 
Offset 39 | 
Operand 18 
modes 118 
Status for code generation 66-67 
types 118 
Operator-operand pair 18 
Operators 18 
phases 15 and 20 141-143 


OPT=0 42 
OPT=1 42 
OPT=2 18 


structural determination 51-54 
Optimization 12 

first level 13 

levels 41-42 


none 13 
second level 13,18 
Options 


boundary alignment 136 
DECK 12,13,63 
determining 14 
EDIT 12,13,18,19,56 
ID 109 
LIST 12,143 
LOAD 12,13,17,63 
MAP 13,63 
SOURCE 19 
XREF 12,25-26 
OP1ICHK-IEKKOP 87,218 
OR 32 
Overlay 202-205 
Supervisor 195 


PACKER-IEKTPK 105,218 
Packing 19 
PAGEHEAD 218 
Parameter list 
optimization 31-32 
table 31 
processing of 14 
PAREN-IEKKPA 87,218 
PARFIX-IEKOPX 102,218 
PAUSE statement 167,176 
PERFOR-IEK@CPF 102,218 
Permanent I/O error 17 
PHASB 218 
Phase loading 15 
Phase switch 206 
Phase 10 12. 
constructing a cross-reference 25-26 
control 19 
initialization 19 
intermediate text 18 
Phase 15 12,13 
CORAL processing 13,36-41 
intermediate text 26 
PHAZ15 processing 12,26-36 
Phase 20 13 
Branching optimization 
OFT=1 49-51 
OPT=2 63 
busy-on-exit information 54-56 
control flow 42-43 
loop selection 56-58 
register assignment 
basic OPT=0 44-46 
full OPT=1 46-49 
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full OPT=2 62-63 
structural determination 51-54 
structured source program listing 56 
text optimization OFPT=2 58-63 

Phase 25 13 . 
address constant reservation 64-65 
Wain program entry coding 65 
prologue and epilogue generation 69 
storage map production 69 
text conversion 65-68 
Phase 30 13,69-70 
PHASS 218 
PHAZSS 218 
PHAZ15 15,204 
PHAZ15-IEKJA 34-35,218 
PH10-IEKCAA 15,78,218 
Planned overlay structure 202 
PLSGEN-IEKVPL 105,218 
Powers 30 
Preparatory subroutine 18,19 
Primary adjective code 20,27 
Primary path 53,54 
Problem program save area 22 
Program 
fetch 15 
interruption mask 176 
termination 177 
Prologue 16,17,64,69 
PROLOG-IEKPTR 68-69,105,218 
Pushdown table 28 
PUTOUT 218 
PUTX-IEKCPX 78,218 


( 


CSAM 16 


Read 
not requiring format 174 
requiring format 173 
READ statement 167 
READ/WRITE 
operator for I/O lists 153 
routines 168-175 
examples of statement processing 
173-174 
Statement 16,20,22,40,66 
uSing namelist 175 
REAL 31 
Real multiplication skeleton instructions 
160 
REDUCE-IEKQSR 61-62,100,218 
REGAS-IEKRRG 47,49,100,218 


Register 
array 66 
assignment 


basic OPT=0 44-46 
full OPT=1 46-49 
full OPT=2 62-63 
rhase 20 43-49,62,63 
tables 129-130 


usage 130 
table 48,49 
Registers, 


reserved 16 
Saving at main program entry 16 
saving at subprogram program entry 16 
Relational operators 32 
Relative address assignment 13,36,37-38 


Relocation : 

dictionary 11,13,41,63 

factor 37 | 
 . of text entries for structural 

determination 51 

RELCOR-IEKRRL 100,218 
RELOPS-LIEKKRE 32,87,218 
Reserved registers 50 
RETURN statement 55 

phase 25 processing of 68 
RETURN-IEKTRN 68,105,218 
REWIND statement 167 
RLD 

entry point 218 

record 41 


RMAJOR table 33,35,51,204 


Root segment 13,202 
RUSE table 49,129 
Save areas 16-17 


Scale factor 23 
SEARCH-IEKRS 100,219 
Secondary entry point 17 
Segment control word 176 
Sequence numbers 21 
SF skeleton text 15,132 
phase 10 18 
format 139 
Shift skeleton instructions 159 
SHFTL 212 
SHFTR 212 
Simple stores 
elimination of 60 
example of 164 
Skeleton 
-array 66 
instructions 67 
SNGL 31 
SOURCE option 19 
source 
module, listing of 12 
program, structured listing of 56 
statement errors, object-time 188 
statement processing table 77 
‘Space 
in adcon table 36 
allocation, phase 15 36 
reservation of 41 
Span 38 
Special argument text « 152 
Special text 132 
Spill register 49 
SPLRA-IEKRSL 45-46,100,219 
SRPRIZ-IEKQAA 56,102,219 
SSTAT-IEKRSS 45,101,219 
STALL-IEKGST 19,79 
functions of 22-24 
Standard text, phase 15 format of 
otatement 
functions 27,28, 132 
processing of 21 
Skeleton 32 
number 
chain reordering 26,34-35 
as a definition 27 
phase 15 format 141 
phase 25 processing of 65 
processing for XREF 25 


144-145 


Statement number/array table 64,120-123 

block status field 121-122 

dimension entry format 122 

entry format 120 : 

after XREF 121 
after phases 15, 20, and 25 121 

Status 

field in status mode word 

information 43 

mode word 45 

of operands for code generation 

in register assignment 45 
STOP statement 167,176 
STCPPER-IEKTSR 105,219 
Storage distribution 

phase 10 15 

phase 15 15 

phase 20 16 
Storage map 13 

contents of 069 

production of 69 
Store skeleton instructions 159 
Stored constant 59 
Store-fetch information 118 
Strength reduction 61-62 

example of 165-166 
STRUCTURE statement 212 
Structured source listing 


145-146 


66-67 


12,13,18-19 


STTEST-IEKKST 87,219 
STXTR-IEKRSX 47,49,100,219 
SUBACD-IEKKSA 30,87,219 
SUBGEN-IEKVSU 105,219 


SUBMULT-IEKKSM 30,817,219 


Subprogrars 16,17,30 
not supplied by IBM 55 
table 30,126-127 

Subroutine directory 
FSD 74 
phase 10 78-80 
phase 15 86-87 
phase 20 100-101 
phase 25 105-106 
phase 30 108 

Sukscript 
expressions 28,30 


absorption of constants in 201 
operators, skeleton instructions 158 
text entry 59,151 

Substitute ddnames 14 

SUBSUM-IEKOSM 60,102,219 

Suktract operations, skeleton instructions 
for 155 

Symbol entry for XREF 25 

Symbols, processing for XREF° 25 

SYNADR routine 188 

SYSDIR 17 

SYSIN data set 
SYSLIN data set 
SYSPRINT data set 
SYSPUNCH data set 
SYSUT1 data set 
SYSUT2 data set 


W112, 17 

112,13 
11-12,13,18,25,26,56 
11212; 13 

11-12,19,56 

112 5.25-26 


Takle entry subroutines 20 
Tables used by IHCFIOSH 178 
TARGET-IEKPT 56-58,101,219 
TBIT 31,212 

TENTXT-IEKVIN 69,106,219 


Index 227 


Temporary 28 
in common expression elimination 59 
storage allocation in register 
assignment 49 
Terminal errors, object-time 190 
Termination of compiler 15,17-18 
Test and set operators 148 
Testing a byte logical variable 148 
Text 
additive text, elimination of 62 
block, definition of 27 
blocking 26,27 
conversion, phase 25 65-69 


entry 
Phase 20 format 145 
types 59 


generation subroutines 21 
information, phase 25 63-64 
normal, phase 10 15 
optimization 42,58-63 
bit tables 127-128 
criteria for (table) 99 
SF skeleton 15 
special, phase 10 16 
TIMERC 219 
TNSFM-IEKRTF 101,219 
TOPO-IEKTPO 51,52-53,101,219 
TOUT 219 
Trace 210 
Traceback 190 
Translation of data text 36,37 
Tree notation, balanced 114 
Triplet 28 
TRUSE table 48,129 
TSP 219 
TSTSET-IEKVTS 106,219 
TXT entry point 219 
TXT records 16,22,63 
TXTLAB-IEKLAB 87,219 
TXTREG-IEKLRG 87,219 
Type 20 
TYPES table 58-59 
TYPLOC-IEKQTL 101,220 


Unary minus 28,30 
skeleton instructions 158 
UNARY-IEKKUN 30, 87,220 
Undefined statement numbers 22,23 
Unit 
assignment table 178,179-180 
in IHCDIOSH 184-185 
blocks 178 
in IHCDIOSH 183 
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UNRGEN-IEKVUN 106,220 
Usage count 22 
Use vector field 144 
Utility 
routines 176-177 
sukroutines 19,21-22 
list of 102 


Variakle, 
adcon 40 
base 40 


dictionary entry 116-118 
after common block processing 119 
after coordinate assignment 119 
after relative address assignment 119 
after XREF 118 

equivalence 20 

Variakles 
rechaining 22,23 
relative addresses for 38 


WRITE statement 167 
Write 
not requiring format 174 
requiring format 173 
to operator routines 176 
WRITEX-IEKOWT 102,220 
WIO 176 
WITOR’ 176 


XARITH-IEKCAR 17,220 
XCLASS-IEKDCL 79,220 
XDATYP-IEFKCDTI 79,220 
XDO-IEKCDO 79,220 
XGO-IEKCGC 79,220 
XICOP-IEKCIO 79,220 
XIOPST-IEKDIO 80,220 
XPELIM-IEKQXM 58-60,101,220 
XREF 

buffer 25 

ortion 12,25-26 

phase 10 preparation for 25 

processing 25-26 
XREF-IEKXRF 25-26,203,220 
XSCAN-IEKOXS 102,220 
XSPECS-IEKCSP 80,220 
XSUBPG-IEKCSR 80,220 
XTNDED-IEKCTN 80,220 


YSCAN-IEKCYS 102 


ZSCAN-IEKQZS 102 
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